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SECTION I - INTRODUCTION 



PURPOSE 

The Applications Software Development Standards 
Manual presents generally accepted methods and 
procedures for system design, programming and 
documentation for BASIC/FOUR system applica- 
tions. Consistency is the key to quality workman- 
ship in the end product. This manual is also in- 
tended for use as an educational tool for personnel 
who are unfamiliar with BASIC/FOUR system 
applications software standards. The standards 
set forth in this manual are used to develop all 
BFC applications software packages. 

SOURCE 

The knowledge and experience necessary to 
develop software standards can only be acquired 
through involvement in software development 
and field experience with BASIC/FOUR systems. 
The methods and procedures described in this 
manual have been obtained through the contri- 
butions of a variety of analysts and programmers 
with this background. 



REVISIONS 

Since the purpose of this manual is to present 
generally accepted practices, it will be improved 
by suggestions and additional contributions from 
the field. 

CONTENTS 

The use of the standards presented herein provides 
for the adaptation to BASIC/FOUR equipment 
capabilities and the Business BASIC language, and 
also presents terminology and application software 
definitions and requirements. 

The four subjects of concentration are: 

1. BASIC/FOUR Fundamentals 

2. Systems Design 

3. Programming 

4. User Documentation 

The material covering each subject is separated into 
logical sections to highlight the requirements of 
successful applications software development. 
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SECTION II - FUNDAMENTALS 



SYSTEM CHARACTERISTICS 

The BASIC/FOUR system is designed to fulfill 
business processing requirements in the interactive 
time-sharing environment. The system hardware 
consists of the CPU and peripheral devices includ- 
ing magnetic disc drives, line printers, video display 
terminals (VDT's), magnetic tape drives, paper tape 
punches, paper tape readers, card readers, and execu- 
tive display terminals (EDT's). 

Business BASIC is an expansion of the BASIC 
(Beginner's Ail-Purpose Symbolic Instruction Code) 
programming language. It provides the capability 
and flexibility necessary to support the BASIC/ 
FOUR system hardware in an interactive business 
environment. Most of the original problem-solving 
capabilities of BASIC have been retained in Business 
BASIC. Also, all peripherals are supported by com- 
plete formatting and editing capabilities, as required 
by business applications. In most applications dur- 
ing execution, a program displays instructions on 
the VDT screen and the operator simply replies 
by keying in the requested information. 

The Basic Operating System Software (BOSS), for 
Business BASIC provides the interface between the 
interactive terminal users, the hardware, and the 
software components of the BASIC/FOUR system. 
BOSS monitors the operations of each task and allo- 
cates the system resources on a first come, first 
serve basis. BOSS is composed of three major soft- 
ware elements: 

• Business BASIC Interpreter - Interprets 
the Business BASIC language statements 
in order to select the required system 
routines for execution. 

• Program Executive — Provides execution 
scheduling of CPU time, allocates peri- 
pheral devices, controls file organization 
and performs all disc space allocation and 
de-allocation. 



• Configuration — Contains the specifica- 
tions necessary to support the exact hard- 
ware configuration of a BASIC/FOUR 
system. 

Magnetic disc storage is the primary storage medium 
used on the BASIC/FOUR system. Disc capacity 
may be expanded from through the use of off-line 
removable disc packs or additional disc drive(s). 

Data file records stored on magnetic disc are or- 
ganized in variable fixed length format. Once a 
file record size is defined, the disc space required 
is reserved. If a record length is less than the defined 
size, the unused disc space remains available only 
for that record. A record may not exceed the de- 
fined file record length. 

The BASIC/FOUR system has the ability to com- 
municate asynchronously over telephone lines. Re- 
motely located VDT's and printers may use the CPU 
and disc storage located at a home office. Also, 
by using the synchronous communications capability, 
the BASIC/FOUR can communicate with another 
CPU. 



Due to the high degree of system interaction be- 
tween programmers and operating personnel, who 
are subject to error, the system recognizes errors 
made while keying in statements. Error codes are 
issued and immediately displayed on the terminal. 
Errors generated while executing a program are also 
detected by the system, however, such errors are 
usually controlled by the program or instructions 
are displayed. 

Business BASIC is a simple to use, high level lan- 
guage. Although it is semi-documenting, complete 
system design, program and operator documenta- 
tion is critical for any system. Recommended 
documentation forms and suggested formats are 
available which are designed especially for use with 
BASIC/FOUR systems. 
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The absence of forced program formatting in 
Business BASIC, makes it very powerful as well as 
flexible. However, since programs function logically, 
it is sensible that they should be organized logically. 
The programs which together form a system should 
have consistent structure. This simplifies debugging 
during testing and programming changes are easier 
later when modifications or additions are made. 
(Refer to Program Organization). 

It is very important to become familiar with the 
terminology used in conjunction with the BASIC/ 
FOUR system. Analysts, programmers, operators 
and management who communicate accurately, 
produce the best applications software system. The 
Glossary Of Terms includes most of the terms and 
definitions used with the BASIC/FOUR system. 

PROCESSING TYPES 

ON-LINE PROCESSING - The on-line inter- 
active capabilities of the BASIC/FOUR system 
provide the ability to immediately update sys- 
tem files. Updating occurs only after each 
transaction is entered and validated through 
the VDT screen. The information necessary 
to provide hard copy audit trails is usually 
stored in a disc file which is updated by each 
transaction processed. This is the primary 
method of processing used on the BASIC/ 
FOUR system. 

BA TCH PROCESSING - Processing groups of 
related transactions may be implemented using 
magnetic tape, disc, or paper tape batch files, 
prepared off-line. However, batch processing 
is more efficient on the BASIC/FOUR system 
when the interactive, on-line capabilities are 
utilized. This can be done by using the VDT 
for the entry and validation of transactions. 
Once validated, the transactions are grouped 
in a disc file and stored for updating at a later 
time. In most cases, when this method of pro- 
cessing is employed, batch files are printed, 
corrected and balanced before being used to 
update the system files. 



FILE TYPES 

PROGRAM files are one record files which are 
used to store programs on the disc. 

INDEXED files contain data records which 
physically exist in record number sequence 
0 - n, where n + 1 is the allocated number of 
records for the file. The records may be direct- 
ly accessed using the IND= option or accessed 
in sequence. INDEXED files may be used as 
master files, report files, or batch files when 
the file record numbers, 0 - n, are compatible 
with the required processing sequence. Also, 
system control files which may contain small 
amounts of data such as dates, company name, 
and processing statusflags, are often INDEXED 
files. 

DIRECT files contain data records which are 
ordered by "keys" in a file directory. Although 
keys may be variable in length, they should be 
uniform within a file. The DIRECT file is the 
primary file type used on the BASIC/FOUR 
system and may be read randomly using the 
KEY= or IND= options. DIRECT files may be 
read logically according to the key sequence 
OR they may be read logically using the IND= 
option, when no particular record sequence is 
required. 

SORT files contain only keys (no record data) 
and may be used in conjunction with DIRECT 
or INDEXED files to produce "sorted" re- 
ports. Also, SORT files may sometimes be used 
as master files, when only the key information 
is required. 

APPLICATION FUNCTIONS 

BASIC/FOUR system applications software requires 
the consistent use of the following function types: 

File Maintenance Function — necessary to 
create and maintain critical data contained in 
master files. 
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Entry Function — provide for the entry and 
validation of transactions, such as: orders, 
invoices, etc. . . 

Sort/Update Function — allow for the manipu- 
lation of data for reports and files. 



Report Function— provide printed output of 
file data needed by the user. 

inquiry Function — supply visual display of 
master file and/or other information required 
by the user. 

Selector Function — afford a common point 
of beginning and ending processing modules, 
while providing an index of available selec- 
tions. 

Backup and Restore Function — necessary 
to reduce error potential during backup and 
restore operations. 



MAINTENANCE 
DESCRIPTION 

Maintenance functions allow the on-line addition, 
change, deletion, and inquiry of file records. Main- 
tenance programs should be provided for all appli- 
cation master files. 

All relevant record data should be displayed; how- 
ever, total and accumulaton fields generated by the 
application should not be accessible for change. If 
such totals require manual entry at conversion time, 
a special version of maintenance must be provided. 
Fields accessible for change should be numbered. 

Audit trails are generally not produced by main- 
tenance functions; however, a hard copy option is 
often provided. 



PROGRAMMING CONSIDERATIONS 

After displaying the screen format in background, 
or clearing old data, maintenance functions allow 
for the selection of the following processing options 
to be performed on the file: 1 -ADD, 2-CHANGE, 
3— DELETE, 4-INQUIRE, 5— END. 

Upon input, the data field area should be cleared, 
characters printed to indicate the field length and 
the bell rung. This may be accomplished efficiently 
by using a common input routine. 

All possible validation should be performed on each 
field including reading other master files. Always 
display descriptions or names for codes or numbers 
entered. Invalid entries trigger a bell alarm and re- 
quire re-entry of the field. 

The file key data is always the first data input after 
the processing option is entered. Once the key data 
is entered the following procedure is generally 
followed. 

Addition: The file is read to insure that this is not 
a duplicate entry. 

Each field is entered in sequence. A 
IV entry causes the program to return 
to the previous field for re-entry. 

Once all data fields are entered the tran- 
saction is treated as a change. 

Changes: The record is extracted and the existing 
data is displayed. 

The response to a "DATA CORRECT? 
ENTER CR TO PROCEED LINE NO. 
TO CHANGE NN TO VOID" message 
enables the selective change of accessible 
data fields. CR or Function Key I is a 
"NO CHANGE" entry for the data 
fields. 

After all changes are entered the record 
is written to the file. 
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Deletes: The record is extracted and the existing 
data is displayed. 

If the record has active totals or accumu- 
lations, the message "INVALID DE- 
LETE" is printed and the program re- 
turns for another transaction, (process- 
ing option entry). 

The response to "CR TO DELETE 
1 TO VOID", or other similar message 
provides the operator with a "last 
chance" decision option before remov- 
ing the record from this file. 

Inquiry: The file is read and the existing record 
data is displayed. A hard copy option is 
often provided. 

The response to "CR TO PROCEED" 
causes the program to return for the 
next transaction, (processing option or 
the first key field for entry.) 

Reference PROGRAMMING STANDARDS for 
Function Key usage. 



PROGRAMMING CONSIDERATIONS 

The entire screen format is printed in background 
(or old data cleared) prior to beginning transaction 
entry. Upon input the data field area must be 
cleared and printed, to indicate the field length. 
This may be efficiently done by using a common 
input routine. 

All possible validation should be performed on each 
field, including reading other files. Always display 
relevant descriptions, names or amounts obtained 
from validation reads for field entries. Invalid en- 
tries trigger a bell alarm and require re-entry of the 
erroneous field. 

Each field is entered in sequence. A function IV en- 
try during this phase causes the program to return 
to the previous field for re-entry. Once all fields 
have been entered a final "DATA CORRECT?" 
response should be requested before updating the 
affected files. If the data is not correct, the operator 
should be able to access any of the fields for correc- 
tion as well as void the entire entry. 

Reference PROGRAMMING STANDARDS for 
Function Key usage. 



ENTRY 
DESCRIPTION 

Entry functions allow either on-line or batch pro- 
cessing of transactions. 

On-line entry functions facilitate immediate master 
file update requirements while performing validation 
on an individual transaction basis. Audit trails may 
be produced through the use of report files. 

Batch processing entry functions provide for the 
addition, correction, and deletion of transactions 
using a batch file. This method allows balancing and 
correction operations to occur prior to the updating 
of the master file. 



SORT/UPDATE 
DESCRIPTION 

Sorts and updates are always processed on-line. 
SORT files are particularly useful in most sorting 
situations. Updates usually involve master file up- 
dating from transaction or batch files. Sorts usually 
involve the creation of work files from master files. 

PROGRAMMING CONSIDERATIONS 

Password entries are sometimes required before be- 
ginning critical updates. Status flags can be used to 
indicate update in progress and run completion con- 
ditions. This method provides processing control in 
a multiple VDT environment. 
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Extract and/or LOCK should be used in updates and 
sorts and the INDor KEY= function should be used. 

The READRECORD/WRITE RECORD function 
can greatly decrease processing time in sorts and 
updates. 



REPORTS 
DESCRIPTION 

Reports are generally produced on-line from perma- 
nent master or report files. Reports also function as 
part of batch processing when batch listing of 
"proofs" are required. Special situations arise where 
sort or work files must be used to generate the de- 
sired sequence. Updating of files should not take 
place while producing a report due to the increased 
run time and restart considerations. 

If a report must be periodically produced, the fre- 
quency should appear in the report title. All report 
titles should be assigned and referenced consistently 
on all documentation. 

Report headings should include company name, ap- 
plication description, report title, run date, period 
ending date (if any), page, system time, and report 
options selected (if any). Report headings should 
be uniform and centered based on the maximum 
print positions used. Individual field headings should 
be right and left justified for numeric and alpha 
fields. Special forms requirements should be noted 
on all documentation. 

The availability of report options reduce duplication 
of effort in reports and programming, while increas- 
ing flexibility. Options for data selection based on 
date, status, or ranges (starting-ending) should be 
considered. 

All report functions should include restart/reprint 
capabilities. No file should ever be cleared or pro- 
cessing status flags set until the operator indicates 
that the run was successfully completed. 



PROGRAMMING CONSIDERATIONS 

The printing of headings and totals should be in 
subroutines. Totals may be accumulated in arrays 
to reduce program coding. 

All print statements should have error exits to a 
common error handling routine. 

Report progress statements should have error exits 
to a standard error handling routine. 

Report progress should be displayed by indicating 
the current key data or record count on the screen. 
The operator needs to know the current status. 

INQUIRY 
DESCRIPTION 

Inquiry functions operate on-line and usually dis- 
play master file data not available through mainte- 
nance programs. Hard copy options may be pro- 
vided as required. 

PROGRAMMING CONSIDERATIONS 

The screen format is displayed in background. The 
screen foreground is cleared. The key data field is 
entered. If no corresponding record is found on file, 
an "INVALID ENTRY" message is usually dis- 
played and the bell alarm rung. Where multi-screen 
displays are required, the operator should be pro- 
vided with an end option before proceeding to the 
next screen. 

SELECTORS 

DESCRIPTION 

Selectors display the selector identification time, 
date and all application function descriptions. The 
operator is able to select the application functions 
by number. Sub-selectors may be used to group 
function types when there are too many applica- 
tions to fit on one selector screen. 
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PROGRAMMING CONSIDERATIONS 



BACK-UP/RESTORE PROCEDURE 



Upon completion, all programs should link back to 
the selector from which they were run. The master 
selector must have the capability to print and reset 
the system day. 

When "END" is entered on the master selector, a 
BEGIN is executed and "**SYSTEM CLEAR**" 
is printed on the screen. 

Selector program generators are often included in 
systems. In many cases, the available application 
functions for a selector are stored on a file and are 
available for maintenance. 



The Back-Up/Restore Procedure should be pre- 
sented as a processing selection on the system selec- 
tor and is composed of the standard utility label 
controlled disc copy programs or other comparable 
procedure. This provides a controlled back-up 
environment. 

This procedure should function automatically under 
program control. The operator should be told when 
and where to mount labelled discs. The system 
should validate that the correct packs are mounted 
in the correct disc drives before proceeding. Often, 
a logging feature can be used to record error condi- 
tions and recommend recovery techniques. 
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SECTION III - SYSTEM DESIGN 



DESIGN APPROACH 

The BASIC/FOUR system is very powerful and 
affords the analyst almost limitless design alterna- 
tives. In order to develop effective, well documented 
applications software systems, the analyst must im- 
plement systematic procedures which act as a guide 
during development. It is important to maintain a 
proper prospective of a project and to plan and 
control its development. 

A system which is well documented and utilizes 
consistent design and programming techniques, is 
highly valued. However, a system must also fulfill 
the user's processing requirements and must be im- 
plemented in accordance with an installation sche- 
dule. In order to develop high quality applications 
software and install it in a timely fashion, it is neces- 
sary to function in an organized and methodical 
manner. 

A system should be designed to take full advantage 
of the hardware and language capabilities available. 
Working in an on-line, interactive environment re- 
quires extra planning, especially since multiple user 
terminals are involved. The processing and file 
types available have a definite effect on the system 
design. Disc storage and processing time require- 
ments may vary according to the file and processing 
types selected. 

It is very important to consider the recommended 
design and programming standards during system 
design. The selection of possible design and tech- 
nique alternatives is simplified through the imple- 
mentation of the recommendations presented in 
this manual. This also helps the system development 
to flow smoothly into programming upon the com- 
pletion of design. 

System design must be integrated with the rest of 
the tasks and activities involved in applications soft- 
ware development. During the development of a 



system various stages of completion or, "phases", 
are reached. In order for a system to be produced 
in an organized and efficient manner, these phases 
must be anticipated and planned in advance, with 
each phase leading to the next. 

Upon completion of system design sufficient docu- 
mentation should have been generated to clearly 
define the system requirements, describe the ap- 
plication fuctions and to specify the technical 
methods which will provide the most efficient sys- 
tem possible. This documentation must guide and 
support the programming effort. 

Successful applications software for the BASIC/ 
FOUR system is created by using each of the fol- 
lowing recommendations: 

Utilize the capabilities provided by the 
BASIC/FOUR system. 

Implement design and programmingstandards. 

Implement phased planning and estimating. 

Generate complete documentation which 
clearly defines all system requirements and 
functions. 



SYSTEM DEVELOPMENT 

The basic phases which occur during the system 
development cycle include: 

Requirements Definition and Analysis 

Preliminary Design 

Detail Design 

Software Construction 

Software Certification 

Installation 
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Upon completion of the development cycle, an 
additional phase, Maintenance, provides for the 
system operation and modification activities. 

Operating in a development cycle consisting of 
a series of interrelated tasks and activities, provides 
the ability to develop applications software using a 
systematic approach. Each group of related tasks 
and activities are performed within specific periods 
of time, with one phase leading into another. In 
many cases, major activities may overlap from one 
phase to the next. The overall time dedicated to 
each phase varies greatly from project to project and 
must be controlled by the project manager. 

The phased approach to applications software de- 
velopment has been proven to be very successful. It 
provides a basis for a common structured approach 
to software engineering which can be continually 
improved. By thoroughly defining the tasks and ac- 
tivities necessary in development, projects are made 
easier to plan, estimate and control. During the first 
three phases, Requirements Definition and Analy- 
sis, Preliminary Design and Detail Design, the users 
participate in selecting and evaluating system alter- 
natives and design. The developer can plan the pro- 
ject in both general outline and detail formats. In- 
dividuals are allowed to specialize on phases and 
tasks and may interchange and transfer activities. 

REQUIREMENTS DEFINITION AND ANALYSIS 

This phase is usually performed as a pre-sale or feasi- 
bility study. In order to successfully determine the 
system requirements, a good line of communication 
must be established between the development group 
and the client. It is important to become familiar 
with the clients organization and to deal with the 
highest authority possible. Some of the require- 
ments for the new system may sometimes become 
apparent by determining the inadequacies of the 
existing system. The data and transaction volumes, 
including the expected growth factoraredetermined. 
The hardware configuration which is to be installed 
is verified. 



Once the clients problems and requirements are de- 
fined and documented, the analyst responds by out- 
lining the tasks to be performed in order to satisfy 
those requirements. Once the analyst and the client 
agree on the system definition, a project estimate 
and a detail estimate for the next phase are prepared. 

There are definite advantages to this approach. The 
developer and client are able to define and analyze 
the system requirements in a realistic, logical man- 
ner. Client participation in this phase provides the 
client with the opportunity to solidify his objectives. 
A complete statement of processing requirements 
is generated which can be used as a basis for further 
planning and development. (See Work Statement). 

The number of costly changes is greatly reduced by 
having a good, documented requirements definition 
to work from. 



PRELIMINARY DESIGN 

The use of a "top down" design technique, from the 
management level down to a level of detail which 
identifies the major design features, is used to de- 
scribe the appropriate design solutions. The design 
alternatives are evaluated on a cost-benefit basis and 
must be thoroughly reviewed by the development 
group as well as the client. Upon selection of an al- 
ternative, an implementation plan is developed, 
the project estimate is updated and the next phase 
is estimated in detail. 

The "top down" design technique; designing a sys- 
tem beginning with the problem level and working 
down to the computing system level, aides in the 
analysis process. Cooperation between the analyst 
and client enables the selection of the optimum al- 
ternative solution. The participation of the develop- 
ment group helps to insure technical feasibility and 
system efficiency. 
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DETAIL DESIGN 

The deisgn alternative selected in the Preliminary 
Design phase must be documented in detail in order 
to support the coding effort. The design should be 
logically tested, reviewed and documented to con- 
firm its validity before coding is begun. The design 
is reviewed by the development team and the system 
logic and procedures are thoroughly checked. The 
client signs a system design acceptance letter and a 
detail plan and schedule is prepared. 

The client and development group again work to- 
gether during this phase to confirm the logic and 
correctness of the design. Errors which are detected 
and corrected now, are far less costly than if they 
are found after coding begins. The planning and 
testing of the system are greatly simplified by a tho- 
rough, well tested and documented system design. 

SOFTWARE CONSTRUCTION 

A complete and well documented system design 
greatly simplifies the coding effort. The coding 
generated in this phase must fulfill the system re- 
quirements as reflected in the system design. Pro- 
gram specifications, file record formats, VDT for- 
mats, report formats and a production schedule for 
the coding and testing of system functions are all 
critical during this phase. The program structure 
and coding techniques used should be consistant 
throughout the system. All detail documentation, 
including operator instructions, is continually being 
updated and/or written as coding proceeds. 

A production schedule for program development 
greatly simplifies program and system debugging. 
Uniformity and consistency are also very critical 
factors in reducing debugging time as well as main- 
tenance and modification time later. The use of com- 
mon routines to accomplish this is very effective. 

SOFTWARE CERTIFICATION 

The system must satisfy comprehensive testing 
which uses "live" client data. Every program func- 
tion is thoroughly tested by someone other than the 



author. System integration features are tested to in- 
sure accuracy. Also the documentation is reviewed 
to make sure it is complete. Client operations per- 
sonnel training is begun. 

Upon completion of the system testing by the de- 
velopment group, the programs are demonstrated 
to the client for his approval. There should be no 
surprises unveiled during the demonstration due to 
the client's involvement during development. The 
system requirements and design have been previ- 
ously approved by the client, the system compo- 
nents have been completely tested and all input/out- 
put formats and other documentation have been 
previously reviewed with the client. Any minor 
changes requested are made and the client signs the 
program certification letter which activates ship- 
ment of the hardware for installation. 

INSTALLATION 

The application programs are transferred to the 
clients system. The system documentation is de- 
livered and the operator training is completed using 
existing test data. The data files are loaded by 
means of manual entry or automated conversion. 
Once live processing begins an installation sign off 
is obtained which begins the pre-determined war- 
ranty period. An analyst is assigned to assist the 
customer in adjusting to the new system and resolve 
any minor problems which may arise. 

MAINTENANCE 

Once the warranty period expires, the client may 
occasionally require assistance to satisfy additional 
requirements. The same procedures are used during 
this phase as are described for development. Changes 
and additions must be carefully designed, tested, 
analyzed, reviewed and documented. It is impera- 
tive that the system documentation is continually 
updated and kept current. No change should take 
place before the documentation is revised. If an 
existing program is being changed, a copy of the 
program should be stored and the live data files 
must be protected until the revised program is cer- 
tified. 
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The systematic development of applications soft- 
ware is very rewarding in the Maintenance phase. 
Programmers not involved in the original develop- 
ment of the system are more easily able to-work 
with a system which is well documented and pro- 
grammed using consistant techniques. 



SCHEDULING 

Many of the defined development activities overlap 
into various phases. The life cycle of the systematic 
applications software development activities and 
phases is reflected in the accompanying chart. 



COMMON ENTRY ROUTINE - PROVIDES ALL POSSIBLE VALIDATION EOR fcMfcY 
DATA BASED ON PARAMETERS. 

7700 PRINT ?}(P7,L7), 
7710 GOSUB 7900 

7750 PRINT *(P7,L7),Z0*(lfL8),2B$(l#S)f 

7760 INPUT »(P7,L7) , 'R«' ,X7$, 

7770 UN CTLG0T077»U,778u, 7/90, 7790.7860 

7 7 80 IF X0 = 2G0TO7 87 0---(X0 = PR0CESSlNG-UPTIUN--l = AL)O,2 = CHANC,E,ETC. ) 
7790 IF LEN(X7*)>L8GOTO7700 
7800 UN N7GOT07*40,7610 

7820 LET X7=NUtf (X7$,EKK=7700D , X7S=Z74(1 , L8-L£N(X !$) )+X7$ 
7630 IF CTLs2LETX7bX7*(-1) 
7840 IF CTL=3L£TX7$="",X7=0 

7 850 ON F7G0T0XXXX, X X X X---- (KHERE-X - 1 S-ST A TEMEM -F 0L LO* I NG-S0I IRCE-G0T0 
7850:) 

7 860 ON F7G0T0XXXX, XX XX---- I WHERE- X- 1 S-ST ATE^EUT - Bfc G I NNI r<lG-PR£ V I0US-EN 
7860:TRY-FIELD) 

7 87 0 ON F 7GOTOXXXX , XXXX---- ( WHfcRE-X-IS-ST A TEMENT-HEGI NN ING-NE X T-fcNTR Y- 
7870tFIELD) 



Common Entry Routine — provides all possible validation for entry data based on parameters. 
Figure 3-1. Common Entry Routine 



ERROR PROCESSING - PRINTS ALL ERROR MESSAGES A.*D PPOCFSSES ALL CCMRdLLARLE ERRORS . 

8000 PRINT aili), 22) , "INVALID PASSWORD. RUN ABORTED", 
8010 GOSUB 7900 
8020 GOTO 9997 



8050 PRINT SK0, 22) , "PRINTER UNAVAILABLE", 
8060 GOSUB 7900 
8070 GOTO 600 



8600 PRINT i>(0,22) , 'LO' , S> ( 1 ,?2) , "ERROR " , E R R , " ON FILE ",F9$d,6), n ST 

8600:MT# ",F9$(7)," CR=RETRY 1 = ABQRT ", 

8610 GOSUB 7900 

8620 INPUT *(55,22) , »R8' ,X7$ 

8630 IF X7S= M 1"GUT08900 

6640 IF X7*<>""GQT06620 

8650 PRINT «)(0,22) , ' LD ' 

8660 RETRY 



8900 PRINT aid #23) » "RUN ABORTED - CALL PROGRAMMER", 
8910 GOSUB 7900 
8920 ESCAPE' 
8930 GOTO 8900 

Error Processing - prints all error messages and processes all controllable errors. 
Figure 3-2. Error Processing Routine Example 
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PASSWORD ENTRY - REQUIRES THE ENTRY OF A COMBINATION OF TWO 
UNPRINTABLE CONTROL CHARACTERS BEFORE A RUN MAY BEGIN. 



0500 LET X»0 

0510 INPUT o)(2, 2) , "ENTER PASSWORD TO PROCEED " , S ( 29 , 2 ) , ' RB ' , X 7 $ 

0520 IF X7$=" "GOT0560 

0530 LET XsX-M 

0540 IF XS3G0T0800O 

0550 GOTO 510 



Password Entry — requires the entry of a combination of two unprintable control characters 
before a run may begin. 



Figure 3-3. Password Entry Routine Example 



PRINTER SELECTION - PROVIDES PROGRAMS REQUIRING THE USE OF A 

PRINTER WITH THE ABILITY FOR THE OPERATOR TO SELECT THE PRINTER TO BE 

USED. THIS ROUTINE ALSO PROVIDES AN END OPTION TO RETURN TO THE CALLING PROGRAM. 

0600 INPUT (0, ERRsb00)o>(2, 2) , 'ID' ,3(2,2) , "ENTER PRINTER SELECTION (1=L 

0600 !P 2 = P1 3=END) " , 9 ( 45 , 2) , ' R8 ' , X 7 $ : ( " 1 " = 6 1 U , " 2 " = 630 , " 3 " = 9997 ) 

0610 LET X7S="LP" 

0620 GOTO 650 

0630 LET X7S="Pl n 

0640 CLOSE (7rERR=641) 

0650 OPEN (7,ERR=8050) X7$ 

0670 PRINT (7, EMR=fi050) »FF ' , 'LF' 

Printer Selection — provides programs requiring the use of a printer with the ability for the opera- 
tor to select the printer to be used. This routine also provides an end option to return to the 
calling program. 



Figure 3-4. Printer Selection Routine Example 



RING BELL LOOP - A SUBROUTINE THAT RINGS THE BELL WITHOUT 
MOVING THE CURSOR FOR ERROR MESSAGES. 



7900 FOR X=lTOlb0 

7910 PRINT ' RB ' , 

7920 NEXT X 

7930 RETURN 



Ring Bell Loop — A sub-routine that rings the bell without moving the cursor for error messages. 
Figure 3-5. Ring Bell Loop Sub-Routine Example 
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SECTION IV - USER DOCUMENTATION 



In order to be complete, a system or program must 
be thoroughly documented as well as functional. 
Documentation is not generated exclusively for the 
programmer or analyst, but must be provided to the 
user upon installation of the system. 

DESIGN DOCUMENTATION 

The requirements for design documentation are: 

A work statement defining the requirements of the 
system. This includes descriptions of: every system 
function, all source and output documents, transac- 
tion volumes, file sizes, and report frequency. Note 
that a more specific definition is done in the program 
specification stage. 

The work statement should be prepared by the 
software vendor, and may be included in the 
proposal to the Customer, then made a part 
of the Application Software Addendum (form 
BFC 1171) by reference. 

The work statement should consist of a mini- 
mum of four sections (Section V is optional). 

I. APPLICATIONS 

II. OPERATION DESCRIPTIONS 

III. VOLUMES 

IV. TERMS AND CONDITIONS 

V. VENDOR QUALIFICATIONS 

(optional) 

When writing the work statement, in the con- 
text of a proposal, use words like "... your 
Payroll System will include ..." Use language 
which the customer can understand, and do 
not include flow charts unless they are ex- 
tremely simple. The work statement need not 
be lengthy, but must define the scope of the 
job that will be done for the customer. 



Start a new page for each section of the work 
statement. Put a date on each page of each sec- 
tion, along with the name of the customer. 
Then, in the Consultant Order and Application 
Software Addendum, refer to the work state- 
ment by date. 

The applications section should contain a nar- 
rative, a list of input documents, a list of out- 
put documents, and an optional flow chart for 
each application. The flowchart must be ex- 
tremely simple and should be included unless 
it is determined to be objectionable or confus- 
ing to the customer. 

If vendor wishes to include his qualifications 
in the work statement, put such qualifications 
at the end, in Section V. 

Sample work statements for a payroll applica- 
tion and an order entry application are shown 
in the Appendix. 

A simple system overview flowchart should illus- 
trate the major processing modules in the system. 
(See Figure 4-2). A comprehensive processing flow- 
chart should reflect all input-process-output flow 
for all application functions (See Figure 4-1 ). 

File Record Formats, BFC Form 1021 (See Figure 
4-4) are required for all files and all record types 
used by the system and are accompanied by Data 
File Definition Sheets, BFC Form 1016 (See Fi- 
gure 4-3). 

VDT Screen Formats are necessary for all system 
functions. BFC Form 1022, accommodates all VDT 
models. However, if only model 7220 and 7230 
screens are to be used, BFC Form 1275, is especial- 
ly designed to allow typing on up to 25 lines with 
80 characters each. A sample VDT screen format is 
provided (See Figure 4-5). 

Report Formatting Sheets, BFC 1023, are required 
for all system reports (See Figure 4-6). 
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A Program /File Matrix, BFC 1 261 , must list all sys- 
tem applications and specify file activity for each 
application (See Figure 4-8). 

The reservation and assignment of file and program 
names must be documented in a means which re- 
flects the assignment scheme. The File/Program 
Assignment Matrix, BFC 1262 (See Figure 4-9), 
is available for this purpose. 



*A Utility Directory Listing, (See BASIC/FOUR 
Utility Manual, BFC 5002 or BFC 5024). 

Program Flow Charts for complex programs only. 

Program documentation is regarded as part of pro- 
gramming and must be completed before the pro- 
gram may be considered finished. 



Program Specifications, BFC 1263, describes the 
purpose of each program and its associated link pro- 
grams, if any (See Figure 4-10). Special conditions 
and requirements should be included such as: pro- 
cessing conditions (flag status checking), algorithms 
and formulas. Files used and updated must be listed 
as well as a detailed description of the logical opera- 
tion required. Care should be taken to cover the 
specifications in enough detail to support the pro- 
gramming phase. 

Milestone Charts, BFC 1161, reflects the project 
schedule (See Figure 4-7). 

System documentation is generated as part of the 
system design phase and is updated as required dur- 
ing the programming and debugging phases. 

PROGRAM DOCUMENTATION 

The requirements for program documentation are: 

*M Utility Program Listings and Analysis, (See 
BASIC/FOUR Utility Manual, BFC 5002 or BFC 
5024). 



OPERATOR DOCUMENTATION 

The requirements for Operator Documentation are: 

Operator Instruction Narratives (See Figure 4-11) 
must describe the application function, the condi- 
tions and/or requirements of operation and the 
output produced. 

Operator Instructions must provide the entry re- 
quirements for each screen field and any processing 
sequence requirements (See Figure 4-12). 

Specify and document all cyclical processing require- 
ments including the daily, weekly, monthly, quar- 
terly and annual cycles. This information is critical 
in order to promote smooth operation of the system. 

The best time for operator' documentation to be 
completed is immediately after the program is writ- 
ten and debugged. However, operator documenta- 
tion must be completed prior to the installation of 
the system. 
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Figure 4-2. Simple System Overview 
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basic /Four corporation 

an MAI company ® 

DATA FILE DEFINITION PAGE __1_ OF _J. 

Fll F IDENT I B i 7 I I SlQ I IrItI PRO.IFCT Savagp Rai l Ftnnris RV FREY DATE XX/XX/XX 



KEY SIZE 
14 


NUMBER 
OF 

RECORDS 


10,000 


RECORD 

SIZE 128 


DISC 
NO 


SECTOR 
NO 


□ PERMANENT □ SEQUENTIAL 

(INDEXED) 
H TEMPORARY ft] DIRECT 
B KEYS ONLY (SORT) 


FILE DESI 


SRIPTION 


KEY = 


= AGENT I.D. 


& BOND 


NUMBER 





SORT FILE FOR AGENT LIABILITIES REPORT 



PROGRAMS WHERE USED. 



CONTENTS 



VAR 
NAME 



An$ 



Bn$ 



ITEM 
SEQ 



ROND 



FIELD NAME 

POWER 

NUMBER 



AGENT I.D. 



5_ 



BOND CODES 



S TATUS 

STATE NO. 



__Dtl$ 4 ... DATES 



Fn$ 



\ Hn$| 



An 



1. 
.8. 

9 



DATE ISSUED _ 1 6. 

DATE EXECU TED/ VOID) 6 

. DATE FORFEITED J..._6_ 

DATE SET ASIDE 

DATE EXONERATED 

FORFEIT DUE DATE 

REPORT #s EXECU TED RPT. # 



EXONERATED RPT. 



COURT I.D. 



CASE._NO, 

DEFENDANT 

TRANSFER. AGENT 



1Q , REWRITE EQED # 



11 



i- — 



PENAL AMOUNT 



SLZE 



_6_ 



__5. 



-± 

15- 
J5._ 
. _9_ 

__a.. 



POSITION 



1 .3 



1 ,6 



TYPE 



A/N 



A/N 



A/N, 



,A/N 



A/N 



A/N 



_A/M 



19,6 



,25,6 



31 ,6 



6,5 



1,6 



A/£J 



A/N 



-A/H 



A/N 



A/N 



A/N 



A/N 



A/N 



PICTURE 



- "9 1 



" 00" - "99" 



" MMDDYY " 



"MMDDYY" 



" MMDDYY" 



-"MMDDYY" 



"MMDDYY" 



" MMDDYY " 



"00000" - "99999" 



"000 00" - "999 99" 



######.00 



'FS 



BFC Form 1016 
September 1976 

COPYRIGHT 1976^ by BASIC/FOUR CORPORATION All rights reserved 
BASIC/FOUR and^* are registered trademarks of BASIC/FOUR CORPORATION 



*FS = FIELD SEPARATOR 

BASIC/FOUR computers are manufactured by BASIC/FOUR CORPORATION, 
a subsidiary of Management Assistance Inc (MAI) 



Figure 4-3. Data File Definition Form (BFC 1016) 
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RECORD FORMAT basic /Four corporation 

an MAI company ® 

FILE INDENT l&Zl tSjgj £jTJ PROttt&ffl&jOBlLMWVi MIL DATE 

_OF^ 



FILE nPsr.RiPTinNi /fc£/Ur LlA& JL/77£S P/cE GeecT /U./oooojxSrp^ / 



BUSINESS BASIC I LANGUAGE USES 110 BYTE SECTORS 

65 Exo/oeeflj&P 



BUSINESS BASIC II LANGUAGE USES 256 BYTE SECTORS 



1 


1 


3 8dioq 


2 
3 




4 

5 


6 
7 
8 
« 


6 
7 
8 
9 


m 


10 


14 LvU * 

15 


11 
12 
13 
14 
15 


16 


1R 


18 aooes 

19 


snvrus 17 

18 

w 


20 


29 



21 

22 IW£ 



21 
22 
23 
24 
25 

_2£j 

27 
28 
29 

30 emoted/ i/atD 30 

321 



23 
24 
25 
2fi_ 
27 
28 
29 



OWE 



32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 



DATE 

FQ£FErrnETl> 
OfYHE 



33 
34 
35 
36 
37 
3£ 



39 
40 
41 
42 
43 
M 



45 



43 SET fVSTOE 

44 

JJ E*©fO££ATHD J| 

50 



51 
52 
53 
54 



H WE DATE 

56 



5.0 

51 
52 
53 
54 
55 
56 



57 

58 

59 EXECUTED 

62 _ 

63 
64 



57 



58 
59 
60 
61 
62 
63 
64 



65 
66 



-52- 



69 

r? dooer 
72 r.o. 

73 

74 



69 
70 
71 
72 
73 
74 



_Z5_ 



75 



76 
77 

80 
81 
82 
83 
84 

-fl5 



76 
77 
78 
79 
80 
81 
82 
83 
84 
85 



87 87 

88 88 

91 91 

92 92 

93 93 

94 94 

95 95 

96 96 

97 97 

98 98 

99 99 
100 ' 100 
101 101 



102 



102 



104 7£/9/l£^/e 



105 
106 
107 



108 



103 
104 
105 
106 
_U2L 



108 



109 

110 

112 

113 SofDD 

114 

115 /L>UM6E£ 

116 

117 



109 
110 



111 
112 
113 
114 
115 
116 
117 



119 119 

1 20 1 20 

121 pe/VQL 121 

122 ' 122 

123 ftMQVAfl 123 

1 24 1 24 

125 125 

1 26 1 26 
-L2Z 127_ 



_L2a_ 



_L2fL 



129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 

161 

162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 



129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 

161 

162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 



193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 

217 

218 

219 

220 



221 

222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 



-STOP HERE FOR BBI- 



193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 

217 

218 

219 

220 



221 

222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 



REMARKS: ^= A^FJCTr X.fl. T P£>A^ A)l>MA£~£ 



BFC Form 1021 
December 1975 



COPYRIGHT 1975 ' by BASIC/FOUR CORPORATION All rights reserved 
BASIC/FOUR and^J* are registered trademarks of BASIC/FOUR CORPORATION 



BASIC/FOUR computers are manulactured by BASIC/FOUR CORPORATION 
a subsidiary ot Management Assistance Inc (MAD 



Figure 4-4. File Record Format Form (BFC 1021) 
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PROJECT — 

SYSTEM -BA/J. &OrtD$ 



VIDEO DISPLAY TERMINAL FORMATTING SHEET 

PROGRAM NAME Gl7j CJC PROGRAMMER. 



basic / Four in 



PROGRAM DESCRIPTION f£M. AqemtMa/ntzname hate /a/*/?*? PAGE L OF Z_ 



012345678 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 3'0 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 



0 X BAIL BONDS - 4£NERAL AGENT MA I HThti AHC £ 
1 

2 EHTBR l-AOD Z-CHAH&E 3-D£L£T£ *J- INQUIRE S-IHO 
3 

4 

5 I 

6 z 

7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 



&ENEKAL A&BNT HO . . 
6ENZKAL A6ZHT HAHIE 

RET £HT I OH % 

ti UM8BR Of AG EHTS . . 



HO, OF ACT/VZ BONDS 
PEHA L I t A8l i. I fi . . . . 
6 ROQ$ PRE N' «M 





# AHMEST * 

Wo 

oo 

00 



xxxxxxxxxxxxxxxxxx 

DO 



# T01AL # 

xxxx* 

.00 
00 




D 



20 ENTER. LINE HO. TO CORRECT OR. CK TO FRoZEBD 

21 

22 £ EKKOR N[ESQfl&ES 
23 

24 

25 
26 

01234567 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 3940 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 



0 

1 

2 
3 
4 

5 
6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 



REMARKS 



{7 



BFC Form 1022 

Revised: September 28, 1971 



REPORT FORMATTING SHEET 

PROJECT 



bbsic/Four corporation 

an MAI company _ ^ ., 

.PROGRAM WtMF 1ST PROGRAM nFSrRIPTIOM YJklY. ACTWTI KpT. PROGRAMMER 



i 



2 Xx/XxAx vn-Crtip.F- ftiS-JFf.uiiF. cowrw)- we 

4 A a £ M T 

* XXX.XX XXXXXX XxXXXXXXXXXXXX we *iu / AcririTi /?£ f 0 ct 

6 

? A £ T I t I T / G F r, H 5 T o T A )- '> 

9 mc^n-c /ww dt.sr aimcu/jt 

10 

n Wr-O^ XX'XX 

u?MnSfekZ . • .......... XXXX ^'XUXjCU'^- 

L £*£<mT , XXA.X jf/OTK . fff /XXXXX . XXWXX . * * XXXXXX ■ f 

16 

i? fckf 1 1 x uk x x xa xy /yxxxx . * * * 

18 

i9.s£r />sr x>« XXXX XXXXXXXX ■ 

20 

VlUCNEKHTlCUS - M6LHT.. XXXX XXXX XXXX • " ' 

23£xc».f.K«T,efJ.s - othlk . XXXX XXAXKXXX-^- 

24 

2^e-mir^s - olj) XXXX X**XXXXX. « - 

2r«-WRir£s - a/£w XXXX XXXXMXX- « - XX\\\\ WWW ^ XXXXXX,^' 

28 
29 

30 turn tah*"** l\ mil i tils XKXX XXXX ■ c *. XXXXXX • £ c XXXXXX, XX XXXX P v 

31 ; 

32 

33 

34 c 
3b 

36 ^ _ . , 

37 
38 

39 # nor >><zlj:of-£ m j-i Acidify ifi.t>w.i-M;Ms- ; 

40 ..... I , 

4' . r ■ i 

42 ' : : \ 

■ ^ ; ^ •. ., .• '.•,,,! , ,;,''';].'' • ,-. •„•, ...{ • • • ~ ; 

BFC Form 1023 COPYRIGHT 1976' by BASIC/FOUR CORPORATION All rights reserved BASIC/FOUR 
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PROGRAM SPECIFICATIONS 

PROGRAM MAMP- O/EAK UNKS 0 F: _0/EA^_ LINKS TO: Q/EAA_ DATE: 10/5/77 

PROGRAM TITLE: BACKLOG STATUS ENTRY PROGRAMMER: CHRIS 

r ' ~~ 

PURPOSE: 

This program allov/s entry of changes to an ETR's "Backlog Status" 
Code, and updates the ETR Summary and Budget/Backlog files accor- 
ding to the change made. 



SPECIFICATIONS: 

Password into the program is (Control C) (Control A) . 

Files accessed are: 1 - O/E10 - ETR Summary - updated. 

2 - O/E30 - Budget/Backlog - updated. 

3 - 0/E25 - Control File - updated. 

Operating sequence of the program is: 

1. Enter ETR number. 

2. Display current backlog status. 

3. Ask operator if status is correct: Yes - go to Step 7. 

No - continue. 

4. Enter desired backlog status. 

5. Display new backlog status. 

6. Go to Step 3. 

7. Update ETR Summary File. 

8. Update Budget/Backlog File. 

9. Go to Step 1. 

The ETR number entered must be on file, the transaction code must 
be A, B, C or D to be accepted. 
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Figure 4-10. Program Specifications Form (BFC 1263) (1 of 3) 
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PROGRAM SPECIFICATIONS 



PROGRAM NAME: Q/EAK 



LINKS OF: 0/EAA_ LINKS TO: Q/EM DATE: 10/5/77 



PROGRAM TITI.F: BACKLOG STATUS ENTRY 



PROGRAMMER: CHRIS 



PURPOSE: 



SPECIFICATIONS: 

If the status is not changed, the program returns to ask for another 
ETR number. 

If a changed status is selected, the following checks are made: 

Validation Made 



Status to be 
Changed To 



Not Approved 

Approved 
Reinstated 



Current status must be approved. 
Month approved must be the same as 
the current system month. 

Current status must be not approved. 

Current status must be Internal 
cancellation. 



The date approved is: 

Set to blanks if final status is not approved. 

Set equal to the system date if the final status is approved 

Not changed if the final status is reinstated. 

When the operator responds that the status is OK: 

1. The updated record is written back to the O/E10 file. 

2. The appropriate system, or add-on record is updated and 
written back to the O/E30 file, as follows: 
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Figure 4-1 0. Program Specifications Form (BFC 1 263) (2 of 3) 
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PROGRAM SPECIFICATIONS 

PROGRAM M A M F • O/EAK LINKS OF- O/EAA ; NKS TO:Q/F,AA DATE: 10/5/77 

PROGRAM TITLE: BACKLOG STATUS ENTRY PROGRAMMER: _CHRIS 

_ ; . 

PURPOSE: 



SPECIFICATIONS: 

A. Not Approved : 

New Orders count decremented by one. 

New Orders amount is reduced by the total sale amount. 
Ending Backlog count decremented by one. 

Ending Backlog amount reduced by the total sale amount. 

B . Approved : 

New Orders count incremented by one. 

New Orders amount increased by the total sale amount. 
Ending Backlog count incremented by one. 

Ending Backlog amount increased by the total sale amount. 

C. Reinstated ; 

Reinstated count is incremented by one. 

Reinstated amount increased by the total sale amount. 

Ending Backlog count is incremented by one . 

Ending Backlog amount is increased by the total sale amount. 

If the Budget/Backlog record does not exist, a 'zero* record for 
both systems and add-ons is written to the file. 

On program termination the Salesman File and Miscellaneous Sort 
File Codes, in the Control File, are set to unsorted. 
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Figure 4-10. Program Specifications Form (BFC 1263) (3 of 3) 
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OPERATING INSTRUCTION NARRATIVE 
SYSTEM: BAIL BONDS 

CUSTOMER: RICHARD H. SAVAGE COMPANY DATE: 11/9/77 

PAGE: 1 of 1 

FUNCTION: RECEIPTS ENTRY SELECTOR ENTRY: 1-1 



DESCRIPTION: 

This on-line entry function provides for the addition or deletion of bonds from the receipts 
file which corresponds to the bond power series. Also, bond files and packs are created for 
new powers. 

CONDITIONS/REQUIREMENTS: 

The following disc packs must be mounted: SBB001, SBB002. On-line bond packs are also 
required. The System Control, System Files Control, Receipts Master, Receipts Log, Receipts 
Control ana bond files are used. All required files must be available. The printer is required 
upon termination of entry. 

When a new power is being added to the system, all system packs are checked to locate disc 
space for the number of bonds requested. If room is found and the pack is not mounted, the 
pack is requested by its label. If there is no room on existing system packs, the program 
requests that a clean disc pack be mounted. A clean disc pack must be a new sealed pack 
from the factory or a pack which has been cleared by running the utility program "*E" (WD 
option) on it. A new label is generated internally for the pack. Manually label this pack ex- 
ternally as soon as possible. 

The number of bonds being received i^ validated to insure that it will not cause the Receipts 
file to overflow. 

The starting and ending bond numbers being added may not already exist on the receipts 
master file. When existing bonds are found on file during processing the form through re- 
ceipts log entry is adjusted accordingly. (When deleting, the bonds must be on the receipts 
file.) 

The appropriate on-line bond file is checked to insure that the starting and ending bonds be- 
ing received are not on file. If the pack for the appropriate bond file is not mounted, it is 
requested by its label name. 

OUTPUT PRODUCED: 

The Receipts Log is printed upon termination of Receipts Entry. The Receipts Log file is 
cleared upon operator response that the log was printed correctly. 

Sample of Operating Instruction Narrative 



Figure 4-1 1 . Sample of Operating Instruction Narrative 
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OPERATOR INSTRUCTIONS 


CUSTOMER: RICHARD H. SAVAGE COMPANY 


SYSTEM: SURETY BONDS 


PAGE 1 of 3 


FUNCTION: GENERAL AGENT MASTER FILE MAINTENANCE DATE 


DESCRIPTION: 




This function provides for the addition, change, deletion and inquiry of General Agent 


Master file records. (Unnumbered fields for inquiry purposes only.) 


fifi n 

r i c l_ u 


INPUT RFSPONSF 

1 IN T U 1 l\L- Jl V- f\ 1 JL 


ENTER 1 —ADD 


Must be a one digit numeric entry from 1 through 5. 


2— CHANGE 




3— DELETE 




A 1 MOI 1 1 R F 




5 — END 




HFNFRAI AHFNT NO 


CR Tursnr returns tn "FNTFR 1— ADD " field for 




re-entry. 




Must be a numeric entry with a maximum length of two. 




Entries less than two characters are automatically padded 




with leading zeros. 




An error condition is created and re-entry required if: 




the transaction type is an ADD and a correspond- 




ing general agent record is found on file. 




the transaction type is a change, delete or inquiry 




and no corresponding record is found. 




if the transaction type ischange, delete or inquiry, 




the general agent record is read and the data dis- 




played. The cursor proceeds to the bottom of the 




screen for further input. 


1. GENERAL AGENT NAME 


CR Cursor returns to "GENERAL AGENT NO. "field 




for re-entry only if the transaction is an addition. 




Entry may be from one to twenty alpha-numeric characters. 




Operator Instructions (1 of 3) 



Figure 4-1 2. Operator Instructions (1 of 3) 
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OPERATOR INSTRUCTIONS 


CUSTOMER: RICHARD H. SAVAGE COMPANY 


SYSTEM: SURETY BONDS 


PAGE 2 of 3 


FUNCTION: GENERAL AGENT MASTER FILE MAINTENANCE DATE 


DESCRIPTION: 




This function provides for the addition, change, deletion and inquiry of General Agent 
Master file records. (Unnumbered fields for inquiry purposes only.) 


FIELD 


INPUT RESPONSE 


2. RETENTION % 


CR Cursor returns to "GENERAL AGENT NAME" 
field for re-entry only if transaction is an addition. 

Entry must be numeric and from .01 through 29.99. 
Maximum entry length is five. 


NUMBER OF AGENTS 


This field is for inquiry purposes only and is not manually 
accessible. It is updated by Agent Master File Maintenance. 


NO. OF ACTIVE BONDS 
PENAL LIABILITY 
GROSS PREMIUM 


Totals are displayed in these fields for both divisions. These 
fields are not manually accessible. 


(ADD/CHANGE ONLY) 

ENTERLINE NO.TOCORRECT CR Writes record dataand returns to"ENTER 1 -ADD 
OR CR TO PROCEED ..." field for the next transaction. 




1—2 Cursor returns to corresponding field number for 
re-entry. 


(DELETE ONLY) 
ENTER CR TO DELETE 
1 TO BYPASS 


CR Deletes record from file and returns to "ENTER 
1— ADD . . ." field for next transaction. 

1 Cursor returns to "ENTER 1— ADD . . ." field. 
Record not deleted. 

Operator Instructions (2 of 3) 



Figure 4-1 2. Operator Instructions (2 of 3) 
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OPERATOR INSTRUCTIONS 
CUSTOMER: RICHARD H. SAVAGE COMPANY 

SYSTEM: SURETY BONDS PAGE 3 of 3 

FUNCTION: GENERAL AGENT MASTER FILE MAINTENANCE DATE 

\ 

DESCRIPTION: 

This function provides for the addition, change, deletion and inquiry of General Agent 
Master file records. (Unnumbered fields for inquiry purposes only.) 



FIELD 



INPUT 



RESPONSE 



(INQUIRE ONLY) 



NOTE: A general agent record may not be deleted if: 



the "NUMBER OF AGENTS" field is not zero. 



any of the total fields are not zero. 



CR TO PROCEED 



CR Cursor returns to the "ENTER 1 —ADD 
field for the next transaction. 



(ERRORS ONLY) 



ERROR XX ON FILE 
XX STMT XXXX 
CR-RETRY 1 —ABORT 



CR The program re-executes to statement where the 
error occurred. 

1 The program is aborted. Call a programmer im- 

mediately. 

Always retry and look up the error condition before 
aborting. Errors are generated by operation conditions as 
well as hardware failure. A pack not mounted, a pack not 
ready, another VDT holding up a record or file, are all 
conditions to keep in mind. 



Operator Instructions (3 of 3) 



Figure 4-12. Operator Instructions (3 of 3) 



DATE 


TITLE 


Standards Manual 


PAGE 


2/28/77 




User Documentation 


33 



APPENDIX I - SAMPLE WORK STATEMENT 
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SECTION I - APPLICATIONS 



CUSTOMER NAME 
DATE 



A. PAYROLL 



1 . System Flpw 








W-2 's 




941»s 


P/R 
Reporting 




Quarterly 
Tax Reports | 



Insurance 
Reporting 



2 . System Description 



Your pay 
roll mas 
will be 
printed 
labor di 
weekly p 
be proce 
Annually 



roll system will 
ter disc file on 
updated on-line 
from the work fi 
stribution and i 
rocessing cycle, 
ssed to print th 
the W-2's will 



process time sheets against a pay- 

a weekly cycle. The payroll master 
and the checks and register will be 
le. Your system will also include 
nsurance reporting as part of the 

Quarterly, the payroll master will 
e 941 and quarterly tax reports. 

be produced by the system. 



Figure A 1-1 . Sample Work Statement (1 of 7) 
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CUSTOMER NAME 

DATE 

3 . Input Documents 

The source documents for your payroll system will be the 
following : 

1. Hourly payroll time sheets 

2. Salary payroll time sheets 

3 . Deductions 

4. New employees, terminations, address changes 

4 . Output Documents 

Your payroll system will produce the following documents : 

1. Payroll Checks: weekly and semi-monthly 

2. Payroll Register: weekly and semi-monthly 

3. Payroll Check Register: weekly and semi-monthly 

4. Insurance premium, union, pension reports: monthly 

5. 9 41' s and quarterly tax report, FDI , FUI , FUT, FICA, 
Federal Withholding Tax, State Withholding Tax 

6. W-2's 

NOTE: It is imperative that the vendor obtain a clear 
understanding of prospect's unusual payroll require- 
ments (e.g., labor distribution, workman's compensa- 
tion, union report, incentive considerations, multi- 
state, mu lti- company , and so on). 

B. ORDER ENTRY 



1 . System Flow 




Figure A 1-1 . Sample Work Statement (2 of 7) 
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CUSTOMER NAME 

DATE 

\ 

2. System Description 

Your order entry system will process customer orders against 
the customer and inventory master files to produce sales 
orders, invoices, and a customer booking report on a daily 
basis. On demand, a listing of the open orders will be pro- 
duced from the open order file. 



3 . Input Documents 

The source documents for your order entry system will be the 
following : 



1. Customer Orders 

2. New inventory items, changes and deletions 

3. New customers, address changes and deletions 

4 . Output Documents 

Your order entry system will produce the following: 



1. Sales Orders: daily 

2. Invoices: daily 

3. Booking Report: daily 

4. Open sales Orders: on demand, any time payroll processing 
is not being performed 

NOTE: We must indicate the relationship between batch 
operations and on-line operations , and the extent of 
integration of the different applications to be imple- 
mented. 



C. (Next Application etc.) 



Figure A 1-1 . Sample Work Statement (3 of 7) 
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SECTION II - OPERATION DESCRIPTIONS 



CUSTOMER NAME ' 

DATE 

A. PAYROLL 

1. Using the VDT , the following payroll information will be 
entered into your BASIC/FOUR system: new hires, termina- 
tions , pay rate and deductions changes , and employee 
status changes. 

2. On a weekly basis and semi-monthly basis, hours worked, 
vacations, and sick leave will be entered via the VDT for 
each employee. A payroll register will be produced. After 
the input data is verified, changes may be made. Payroll 
checks are then printed along with a payroll check regis- 
ter. Quarter and year-to-date earnings and deductions in- 
formation for all employees are updated on the disc file. 
Monthly payroll reports, insurance premium, union and pen- 
sion reports, and quarterly' 941A reports will be produced 
from the employee records stored. Yearly W-2 forms will 
also be produced. 

NOTE: Spell everything out. Don't use "ETC." Rather than 
refer to "File Maintenance," use customer oriented words 
such as "new hires, terminations, and salary and deduc- 
tion changes . " 

3. It is our recommendation that the payroll application be 
on a separate disc. Each time that you run payroll, the 
disc is then placed in your BASIC/FOUR, computer. With 
this arrangement, it will be necessary to install the 
disc to make inquiries of your payroll files. The follow- 
ing inquiry facilities will be available: 

1. Video display of an employee record 

2. Printout of an employee record 

4. We estimate that your payroll processing will have the 
following timings: 

1. Time sheet entry — 30 minutes 

2. Check printing -- 15 minutes 

3. Register printing — 15 minutes 

These timings are based upon the volumes included in this 
work statement. Variations of the timings are possible in 
a live operating environment. 



r igure A 1-1 . 
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PAGE 


TITLE 


Standards Manual 


DATE 


40 




Sample Work Statement 


2/28/77 



CUSTOMER NAME 



DATE 



B. ORDER ENTRY 



1. All information pertaining to new customers, new inventory 
items and changes of status will be entered using the VDT. 

2. Each day, the incoming orders will be entered via the VDT. 
At the end of the processing, the orders will be printed. 
At the end of each day, the orders entered on that day will 
be listed in the form of a "Booking Report." 



C. (Next Application etc.) 



Figure A 1-1 . Sample Work Statement (5 of 7) 
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SECTION III - VOLUMES 



CUSTOMER NAME 
DATE 



A. PAYROLL 

1. Number of employees. 4 

2. Percentage of turn-over (terminations). 

3. Number of disc sectors. 

B. ORDER ENTRY 

1. Number of orders per day. 

2. Number of lines per order. 

3. Number of back-logged items. 

4. Number of customers. 

5. Number of items. 

6. Average turn-around time from order to invoice 

7. Number of disc sectors. 

C. (Next Application etc.) 



Figure AI-1 . 
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SECTION IV - TERMS AND CONDITIONS 



CUSTOMER NAME 
DATE 



CONVERSION 

The application software will have the functional capabilities neces- 
sary to convert your present system to the BASIC/FOUR system. The 
data preparation and data entry is your responsibility; however, 
your personnel will be trained to handle this function. 

TRAINING 

All application software will be installed in the BASIC/FOUR system 

on-site. This includes up to hours of instruction in operation 

of the software applications. 

DATA VOLUMES 

The volume of data described in Section III of this Work Statement 
are obtained during surveys of your requirements. If the volumes ex- 
ceed those listed in Section III, it is possible that additional 
hardware and/or software expense may be involved in implementing 
your system . 

WARRANTY 

Following the delivery of the Applications Software and acceptance 
thereof, Basic/Four Corporation warrants the software to be free of 
defects for a period of ninety (90) days at no additional cost, pro- 
vided deficiencies can be shown to be of the type caused by poor 
workmanship. This warranty will be voided by any changes to the 
software other than those made by Basic/Four Corporation or its 
contractor . 



Figure A 1-1 . Sample Work Statement (7 of 7) 
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APPLICATIONS SOFTWARE DEVELOPMENT SCHEDULE 



DEVELOPMENT 
FUNCTIONS 



DEF AND 
ANALYSIS 



PRELIMINARY 
DESIGN 



DETAIL 
DESIGN 



SOFTWARE 
CONSTRUCTION 



SOFTWARE 
CERTIFICATION 



INSTALL 



MAINTENANCE 



DEF AND 
ANALYSIS 



PRELIMINARY 
DESIGN 



PRODUCTION 
ACTIVITIES 



FUNCTIONAL 
DESIGN 



PROGRAM 
DESIGN 



CODING 



FUNCTIONAL 
TESTING 



PROGRAM DESIGN 
TESTING AND ANALYSIS 



DEVELOP CERTIFICATION PLAN 



UNIT INTEGRATION 
AND TESTING 



DEVELOP TEST DATA 



CERTIFICATION 
TESTING 



SITE 
TEST 



DEVELOP CONVERSION/ INSTALLATION PLAN 



INSTALL 



DEVELOP TRAINING PLAN 



TRAINING PREPARATION AND TRAINING 



MAJOR 

DOCUMENTATION 



*RQMTS 
DEF 

♦RESPONSE 
TO RQMTS 
DEF 



* PRELIM 
DESIGN 



* FUNCTIONAL SPECIFICATIONS 

* PROGRAM SPECIFICATIONS 

* TEST PLAN 

* INSTALLATION PLAN 

* USER DOCUMENTATION 



PROGRAM INFO 
TEST CASES 
FINAL USER 
DOCUMENTATION 
OPERATOR 
INSTRUCTIONS 



* PROGRAMS 
CERTIFICATION 
SIGN OFF 
I* FINAL 

INSTALLATION 
PLAN 



* INSTALL 
REPORT 



* DOCUMENTATION 
REVIEW AND 
UPDATE 



ESTIMATING 

AND 
PROJECT 
PLANNING 



*PRELIM 
DESIGN 
DETAIL 
ESTIMATE 

♦PROJECT 
ESTIMATE 



* DETAIL 
DESIGN 
DETAIL 
ESTIMATE 

* PROJECT 
ESTIMATE 



* DETAILED PROJECT ESTIMATE 



ESTIMATES FOR 
CHANGES TO 
PROGRAMS AND 
DOCUMENTATION 



REVIEWS 



DEF AND 
ANALYSIS 



PRELIM 
DESIGN 



CRITICAL 
DESIGN 



SOFTWARE 
CONSTRUCTION 



CERTIFICATION 



INSTALL 



PERIODIC MAI NT 
REVIEWS 



A 
SIGN 
OFF 



A 

SIGN 
OFF 



A 

SIGN 
OFF 



APPENDIX II - DESIGN STANDARDS 
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DESIGN STANDARDS 



System design involves the definition and documentation of the requirements of a processing system. In 
order for the system to take full advantage of the hardware and software available, the analyst must design 
the system with the hardware and language capabilities in mind. 

A system should be efficient as well as functional in order to be truly successful. The analyst should imple- 
ment design techniques which capitalize on the available file types, language capabilities, and processing 
types, in order to fulfill the system requirements in the most efficient manner possible. 

The design standards listed in this section are recommended rules to follow during the system design develop- 
ment phase. Each rule is accompanied by a reason or explanation. There may also be a narrative or coded 
example which represents a possible method for implementating the rule. 

STANDARD RULE: 

Design control feature for related application functions in order to insure accuracy and prevent opera- 
tor error. 

REASON: 

Specific processing sequence is often required especially when using work files. These situations must 
be controlled so that they may not be run incorrectly. 

METHOD EXAMPLES: 

This may be done through the use of status flags, on a control file, which are constantly checked and 
updated to reflect the various stages of completion. 



STANDARD RULE: 

All program functions must be capable of operating in a maximum of 26 pages of memory (6656 bytes). 
The recommended breakdown for application programs is 18 pages (18 sectors, 4608 bytes) which 
leaves a proportionate 8 pages of memory (2048 bytes) for data area. 

REASON: 

Controlling the amount of user memory which is available for each task provides for efficient memory 
usage and encourages uniformity in program design. Since BBII allocates the available data area for each 
task, limiting the program size is a method to insure that sufficient data area will be available for pro- 
cessing. 
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Figure Al 1-1 . Terminal Availability Graph 
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STANDARD RULE: 

It is recommended that record size be defined as powers of two (i.e.: 2, 4, 8, 16, 32, 64, 128, 256, 512). 
REASON: 

Record sizes other than powers of two, adversely affect system operating efficiency. This is because 
additional disc rotations are required to read records which overlap sector boundaries. 

STANDARD RULE: 

When possible record sizes should be limited to two (2) sectors, (512 bytes) maximum. 
REASON: 

When working within a limited data area, records which occupy more than 512 bytes are impractical. 
STANDARD RULE: 

When related data does not fit on one record, design two separate files instead of multiple record 
formats. 

REASON: 

Multiple record types existing in the same file are not compatible with language translator programs or 
with EASY, the BASIC/FOUR report generator system. 



STANDARD RULE: 

A scheme of file name assignments should be used consistently throughout the system and should be 
assigned as part of the systems design phase. This provides the ability to easily recognize a file or program. 

REASON: 

It is very important to be able to identify a program or file especially during the debugging phase. 
METHOD EXAMPLES: 

It is recommended that a program name include the system or module, program and overlay (link) 
identification. 

APAAOO 
APAA01 
GLAZOO 



System or Program ^"^^Link 

Module I.D. I.D. Number 

A data file name should include the system or module identification. The remaining four characters 
may be used to uniquely identify the file within the system, according to a consistent scheme. 
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STANDARD RULE: 

The data files and program disc requirements should be defined as part of the system design phase. 
This includes establishing the necessary programs and files on the disc. 

REASON: 

This function should be completed prior to beginning programming in order to promote efficiency and 
organization in the coding/debugging phase. 

STANDARD RULE: 

Always include the key data in the record. 

REASON: 

In case a file directory isaccidently destroyed or the key pointers are in error, a direct file may be easily 
created using the data records if the necessary key data is in the records. 

STANDARD RULE: 

Although the system allows variable length keys in DIRECT and SORT files, keys for a given file should 
be uniform in format and length. 

REASON: 

When it is necessary to read a DIRECT file by building the key with data from other files, inconsistent 
key lengths could cause a problem in accessing the desired record. 

STANDARD RULE: 

The next available sequence number should be stored on ordinal record zero (0) for INDEXED files. 
When using sequence numbers in DIRECT or SORT files store the next available sequence number in 
a control file. 

REASON: 

It is important to maintain strict control of sequence numbers in order to prevent the loss of data due 
to duplicate sequence numbers. 

METHOD EXAMPLES: 

When using sequence numbers, EXTRACT the control record, increment the next available sequence 
number and write back the control record immediately. 

STANDARD RULE: 

Program coding should always support a multi-user environment. 

REASON: 

Although an installation may only have one terminal originally, it is always possible that additional 
equipment may be added later. 

METHOD EXAMPLES: 

Multi-user capability is accomplished through the use of EXTRACT in maintenance and update func- 
tions as well as by using file LOCK in updates or other functions where only single users should be 
allowed. 



PAGE 


TITLE 


Standards Manual 


DATE 


50 




Design Standards 


2/28/77 



STANDARD RULE: 

The system time and date functions should have uniform format throughout the system. 
REASON: 

Although those functions are usually only updated once a day, they appear on all output and should be 
consistent. 

METHOD EXAMPLES: 

The time function should be set using four digits, representing twenty-four hours: HH:MM 

10:00 12:00 14:00 

The time should be output as follows: 

10:00AM 12:00AM 1:00PM 

The system date should be set and output as MO/DA/YR, and should be validated upon entry. 



STANDARD RULE: 

It is recommended that working variables used for such things as flags, line counts, page counts, error 
handling, print masks and printer selection be standard within a system. Standard variable assignments 
should be documented as part of systems design. 

REASON: 

Standard usage of working variables promotes consistency within a system even though several pro- 
grammers may have worked on it. Also, the efficient assignment of data variables decreases the amount 
of user data required for program operation. Programs which use standard variables are easier to follow 
for someone, other than the author or designer, who must make modifications. 

METHOD EXAMPLES: 

A sample variable list is provided on page 63 for reference when studying the sample routines and 
examples in this manual. A list of such standard variables should be included as documentation for 
any system. 



STANDARD RULE: 

Always display the identification of the system and program function being executed. The program or 
link name may also be displayed. 

REASON: 

The operator must be kept informed on what is being processed in order to prevent ESCAPE or pre- 
mature termination of the program. Also, the identification on the screen should agree with system 
documentation thereby encouraging the use of the documentation available. 
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STANDARD RULE: 

Always provide the ability to return immediately to the selector before executing a program. 
REASON: 

Operators sometimes make incorrect selections and should be allowed to return to the selector without 
having to ESCAPE. 



STANDARD RULE: 

The current system time and date information should appear on all output including reports and screens. 
REASON: 

The time and date information is of great aide to an operator when filing reports. The ability to quick- 
ly determine which report of several is most current is often very important. 

STANDARD RULE: 

Always consider the device to be used when designing the I/O formats. 

REASON: 

Various devices have certain limitations which must be considered. For instance, when displaying data 
on an EDT, only 16 lines with 32 characters each may be displayed. 



STANDARD RULE: 

Common routines should be developed and used consistently where ever possible. 

REASON: 

The use of common routines for such things as error handling, data entry and printer selection, pro- 
motes programming efficiency and consistency. Common routines need only be written, keyed in and 
debugged once and then may be stored and merged into memory prior to keying in the rest of a program. 
(See Common Routines) 

STANDARD RULE: 

Implement a consistent scheme for the use of the Function Keys (motor bars). 

REASON: 

The use of the Function Keys increases operator efficiency especially when the 10-key numeric keys 
are used. When used, each of the Function Keys (I— IV) should have a predictable, pre-determined 
result. 

METHOD EXAMPLES: 

The Function Keys may be used effectively in entry and maintenance functions as follows: 

CR or I — The new entry is accepted or "no change" occurs during selective field correction of 
existing data. 

II — A numeric entry is automatically converted to a negative number. 

III — The data field is set to null. 

IV — The cursor returns to the previous data field for re-entry. 
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- PROGRAMMING STANDARDS 
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PROGRAMMING STANDARDS 



No two programmers enforce programming techniques in exactly the same manner. Whether or not the same 
methods are used is not as important as the overall consistency from program to program in a system. 

The following list of standard rules are recommended in order to avoid serious problems and promote the 
development of reliable and consistent applications software. Each rule or goal is accompanied by a reason 
or explanation. In some cases, coded examples or written explanations of appropriate methods to accomplish 
the goal are also included. 



STANDARD RULE: 

Provide for all types of errors and use a common error routine which provides retry capability (especial- 
ly for I/O activities). It is recommended to display the error code, the file name and the statement 
number as part of an error retry routine. Errors that are anticipated, such as 1 1 -missing record, should 
be handled internally, by using the DOM= option. 

REASON: 

An operator should be allowed to RETRY error conditions without having the screen destroyed. Process- 
ing generated error conditions such as 1 1 , should be anticipated by the programmer and code included 
to handle such a situation internally. 



METHOD EXAMPLES: 

See COMMON ROUTINES 



STANDARD RULE: 

Always accompany an ERASE directive with either a DIRECT, INDEXED or SORT directive in the 
same program. 

REASON: 

It is important to maintain strict control duringfile clear operations. This activity should be performed 
in a straight forward manner which is easy to follow. 

If a file is not re-created immediately after being erased, it is possible that the disc space where the file 
was located could be allocated for another purpose before the proper file is re-defined. 

Also, files which are periodically cleared are often used by many programs. If such a file is not immedi- 
ately re-defined after being erased, the code necessary to re-define the file must be included in all of the 
program functions which use it. 



STANDARD RULE: 

Use the FID function to obtain the file information necessary to ERASE and re-establish a file. 
REASON: 

When the FID function is used in programs, the "hard" coding of file information is eliminated. This 
makes a system more flexible. If the disc location of a file is changed, no program changes are required. 
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STANDARDS REVISION COMMITTEE (continued) 
SECTION ^Mfi^/Wt'7Z/<& 
METHOD EXAMPLES: 



PAGE 



RULE # : 



0010 
0100 
0120 
0130 
1110 
1120 
1130 
11«0 
1150 
1160 
1165 
1170 
1180 
1190 
1200 
1210 
1220 
1230 
1240 
1250 
1260 
1270 
1290 
1300 
1310 
1320 
1330 
1340 
1350 
9999 



REM "FILEin — PROGRAM TO PRINT FILE ID 
BEGIN 

DEF FNACA, X4)=ASC (X$(A, 1) ) 

DEF FNB (A, X$)=ASC (X$(A, 1) ) *25b*ASC t X$ (A + l , 1 ) ) 

INPUT (0,ERR=1 1 10) 'CS' , *> ( 1 0 , 10) , "ENTER FILE NAME M , N$ : (LEN = 1 , 6 ) 
OPEN (1 ,ERR = 1 1 10) N$ 
LET X1$=FID(1,ERR=1110) 
PRINT "FILE NAME: ",XlS(lr6) 
LET X=FNA(7rXl$) 

LET X1 = INT(X/16),X2 = X-X1M6,Y$=»FILE TYPE: " 
PRINT "OISC NUMBER: ",X1 
ON X2/2G0T01 1*0, 1220, 1200 
PRINT Y$r " INDEXED" 
GOTO 1300 

PRINT Y$i "PROGRAM" 
GOTO 1300 

REM "FILE IS EITHER DIRECT OR SORT 
REM "NO RECORD SIZE MEANS IT IS SORT 
IF FNb(13,XU)=0GOTO1270 
PRINT YS, "DIRECT" 
GuTO 1290 
PRINT YJ5,"S0RI" 
PRIMT "KEY SIZE: 
PRINT "NUMBER OF 



",FNA(8,X1$) 
RECORDS: ",FNB(9,X1$) 
IF FNBtl 1 t X1$)>0PRI NT" RECORD SIZE: " , FNB ( 1 1 , X 1 $ ) 
PRINT "FILE LOCATION: " , FNb ( 1 3 , X 1 $) 



INPUf "ENTER 
CLOSE CI) 
60T0 1000 
END 



CR TO CONTINUE 



Figure Al 1 1-1 . FID Routine Example 
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STANDARD RULE: 

The READRECORD directive in conjunction with the SIZ= option may be used to accept entry in re- 
sponse to direct questions. 

REASON: 

The use of READRECORD reduces key strokes because no CR entry is required as a field terminator. 
However, the use of READRECORD is impractical when more than 1 character must be entered, be- 
cause it does not have all of the validation capabilities available with INPUT. 

1000 PRINT 3(10,10), "DO YOU WANT A HARD COPY? CY/N) '» , 

1010 READRECORD ( 0 , S I Zs 1 ) B ( 45 , 1 0 ) , X7$ 

1020 IF X7$="N"GOT09000 

1030 IF X7$<>"Y"r,OT01000 

STANDARD RULE: 

Always increment statement numbers by at least ten. 

REASON: 

This allows room for future corrections and modifications. The renumbering utility, *P and *Q support 
this technique. 

STANDARD RULE: 

Always complete a logic loop, (FOR/NEXTor GOSUB). EXIT TO is the only other acceptable method 
of exiting such logic. 
REASON: 

The operating system wll support as many open GOSUB and FOR/NEXT loops as the available data 
area will allow. An error is not generated if such routines are improperly exited (i.e.: by a GO TO). 
However, in order for a program to be easily modified, such routines should follow a logical pattern 
and come to a logical end. 

METHOD EXAMPLES: 

1050 GOSUB 7000 

7000 FOR X = 1 TO 5 

7010 IF A$(X,1)="0" EXIT TO 7030 

7020 NEXT 

7030 RETURN 

STANDARD RULE: 

The current record key or index data should always be available in a variable. 

REASON: 

In case of a system or program error, the availability of the current key or index may be critical in order 
to solve the problem. It is possible that the file pointer does not contain the applicable information. 

METHOD EXAMPLES: 

Use a key or index function when accessing a file. However, this does cause an additional disc access. 
OR 

If high volumes present a timing problem, using the key or index function may be eliminated. However, 
the current record key (or index) data must be available for error handling. This can also be done by 
storing the prior record key (or index) in a variable and executing a dummy read and a key (or index) 
function as part.of the common error processing routine. 
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STANDARD RULE: 

All date entries should be validated thoroughly. 



REASON: 

Dates are often used as the basis for payment selections, commissions, and management level reports. 

METHOD EXAMPLES: 

1010 INPUT (0,ERROR=1010)X$:(8,8) 

1020 IF X$(1 ,2)< "01"ORX$(1,2)> "12" OR X$(3,1)<> "/" 
ORX$(4,2)< "01"ORX$(4,2)> "31 " OR X$(6,1 ) <> "/" 
ORX$(7,2)< "76"OR X$(7,2)> "90" GOTO 1010 

If a valid date is stored as part of the system, use the month and year values for validation if feasible. 



STANDARD RULE: 

Indicate the program progress on the screen during sort, update or report processing functions. 
REASON: 

This enables the operator to estimate the time of completion. Also, this alerts the operator if a program 
is erroneously caught in a loop, or other type of error situation which does not generate a system error. 

METHOD EXAMPLES: 

This is done by printing the source file key, the index or a record count on the screen. If high record 
volume warrants, print the key or other data for every twenty-fifth record (or other convenient interval) 
and print the current key data as part of the common error handling routine. 



STANDARD RULE: 

Working variables usage should be recorded for each program. 

REASON: 

The existing variables name usage becomes critically important when changes must be made to a program. 



STANDARD RULE: 

It is recommended that data variables obtained by reading a file as well as data variables being prepared 
to be written to a file, reflect the current device number assignment of the file. String variable names 
then range from An$ through Zn$. Numeric variables range from An through Zn with the exception 
of arrays, (n represents device number) 

REASON: 

This allows for control of data variables, prevents accidental usage duplication and is of great aide to 
another programmer who may later have to work with the program. 
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METHOD EXAMPLES: 
File Data Variables. 

1050 READ (1 ,END=9000,ERR=8600,KEY=X1 $)A1 $,B1 $,C1 $,D1 $,A1 ,B1 ,C1 
1200 READRECORD (2,END=9000,ERR=8600,KEY=X2$)A2$ 

STANDARD RULE: 

The variable used for file key or index values should be consistent and reflect the current device num- 
ber assignment of the file. 

REASON: 

It is important that the key or index value can be easily identified. 
METHOD EXAMPLES: 

A variable that would seldom conflict in keeping with the file data variable assignment standard is X. 
Therefore, it is recommended that key data variables be Xn$ and index values be represented by Xn. 
(n is the file device number) 



DATE 


TITLE 


Standards Manual 


PAGE 


2/28/77 




Programming Standards 


59 



PROGRAM ORGANIZATION 



Every program has an appointed task, whether it be the entry of data for storage on disc or the production 
of a report. Aside from the obvious purpose of the program, there are several logical processes which every 
complete program must include. It is logical, and not incompatible with the BASIC/FOUR system, that 
these processing operations be physically located within the program in the same sequence in which they 
occur. (See Diagram) 

PROGRAM IDENTIFICATION 

This mandatory section of code consists of remark statements which provide the program name and descrip- 
tion, the system to which the program belongs, the revision date, author initials, link information, and 
(optional) the device number's assignment description. This section occupies statements 10 through 99 and 
is always the first coding in the program. 

INITIALIZATION 

This section of code performs "housekeeping" duties, such as clearing memory, screen set up, opening files, 
setting constants, and printer selection. It begins at statement number 100 and may continue through state- 
ment number 999. This section is omitted in the instance of "overlay" or "link" programs where initializa- 
tion has already been performed. 

PROCESSING 

The processing section is the coding executed to accomplish the defined task, such as produce a report, 
accept data entry, or store the data on disc. The logic is executed repeatedly until the task is completed. 
This section of code occupies statements 1 000 through 6999. 

SUB ROUTINES 

This section of code contains routines which may be repeatedly used from different locations in the program. 
File accesses, common data entry routines, and formula calculations are a few examples. This section 
occupies statements 7000 through 7999. 

ERROR PROCESSING 

A complete program must contain logic to correctly handle all possible error conditions. An error must 
never be ignored. The Error Processing section contains all routines necessary for error handling and occupies 
statement number 8000 through 8999. 

TERMINATION 

This section performs the logical steps necessary to terminate the program. This includes setting flags, print- 
ing totals, and returning to the index program or program link. Also included in this section are mandatory 
program identification and "END" statements. The Termination section is located in statement numbers 
9000 through 9999. 
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PROGRAM ORGANIZATION 
DIAGRAM 



Statement 
Numbers 
10 - 99 



1. 

IDENTIFICATION 
SECTION 



Statement 
Numbers 
100 - 999 



Statement 
Numbers 
1000 - 6999 



Statement 
Numbers 
7000 - 7999 



Statement 
Numbers 
9000 - 9999 



2. 



INITIALIZATION 
SECTION 



V 



3. 



PROCESSING 
SECTION 



4. 



SUB-ROUTINES 
SECTION 



6. 

->| TERMINATION 
SECTION 



5. 

ERROR 
PROCESSING 
SECTION 



Statement 

Numbers 

8000-8999 



OPTION: If the above diagrammed statement numbering scheme is 
not used, "REM" statements must be used to head each logical 
section. Each section should consistently use the same number- 
ing scheme throughout the system. 



Figure All 1-2. Program Organization Diagram 
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,00-"fL9=99.P9rl 



1000 - b99*" 



REM "IDENTIFICATION btClK.ni 10 - 99" 
*£M "aPXXOO - OPEN INVOICES LISTING" 
rffcM " A/P S Y S T t " 
REM "LINKS TO APXAuu" 
REM "Oy/Ul/7b" 

REM "(1)=0PEN PAYABLtS ( 7 ) sPK'l NT fcK " '" 
REM H 1 1 j I T IALIZAT Iii.M SECTION 100 - 999" 
bEGlN 

LET Y $= n UH»U». oO-" , L%*"ttuUUtlU 
UIM A (3) ,b(3) 

IOLIST AlS,bl*,ClS,A(l),A(2),A(3) 

PRINT 'CS' , ' SB « , a iCl , 0) , " A/P - VEnDUR INVOICE LIST" 
OPEN (7 ,£RR=80bO) "LP" 
LET F9a> = "AP0PENU20U" 
OPEN ( 1 ,ERR=6100) "APUPEN" 

INPUT (0,tkk = 210)<u(l , 3) , "ENTER CP TO PROCEED OP END " , X 8 : I " " = 1 0 0 0 
0210:, "EN0"=9997 ) 
1000 REM "PkuCESSING SECTION 
LET F95="APOPENlO20" 
READ (1 , ENU=9000,ERR=6bOO) IOL=140 
PRINT «(lfSOJrAlS» 
IF L9>i4GOSUb70lO 
LET P9*="LP 1050" 

PkINT l7,ERR = 8b00)AlS,a>(10),bl5#*(40),Cia»,riKbb)rA(l):Y$,<ii(bb),A(2 
):YS,*l7b),A(3)!Y5> 
LET L9=L9+1 
FUR X=lTOi 
LtT rt (X) =b (X) +A (X) 
NEXT X 
GOTO lulO 

REM "SUb-KOUT INES SECTION 700U - 
LET F9$="LP 7u20" 
PR I ,v T (7,ERR=BbOu)'FF , ,'LF',"DATE 
AT ION", oJl7b) , "PAGE " , P 9 : " & 0 " , ' L F 1 
, V-V .PM1N1 (7,EP,K = 6b00) " V t NI)OR " , a» ( 1 0 ) , "NAME" »a (40) , "1NV0ICE 
7 030: , "AMUU.MT " ,<D tbbj , " TOT -PAID",ai( / bj . "bALANCE" . ' LF ' 
7040 LET P9=P9+l,L9=b 
RETURN 

FOR X=1TU1U0 
P P I N T ' R b ' , . 
nE*1 X 

RETURN 

REM "ERROR PROCESSING SECTION 8000-6999" 
PRINT » ( 0 » «? 2 ) # " P N I N T E W UNAVAILABLE", 
GOSUb 7900 
GOTU 9997 

PRINT *J(U, 22), F9$(l, 6)," FILE UNAVAILABLE", 

GOTO dObU 

PHINI «lo» 22) , 'LD ' #*>(1 > 221 , "tRKUK " , E R R , 
MT U ",F9iC7)," Ck-RETRY 1-ABOKl ", 

GOSUB 7900 



0010 
0020 
0030 
0040 
0050 
OObO 
0100 
0110 
0120 
0130 
0140 
OlbO 
0180 
0190 
0200 
0210 



1010 
1020 
1030 
1040 
lObO 
lObO 
lObO 
1070 
1080 
1090 
1100 
1110 
7000 
7010 
7020 
7020 
7030 



7999" 

",UAY,a)(30) , "BASIC/FOUR CORPOR 

N0."fa)lb7) 



70b0 
7900 
7910 
7920 
7930 
8000 
80b0 
8080 
8070 
8100 
6110 
8bOO 
8b00 
8810 
8b20 
8b30 
8b40 
86bO 
8bb0 
6900 
6910 
8920 
6930 
9000 
9010 
902U 



UN MLE ",F94(l,b) 



ST 



INPUT u(bb,^) , ' Rb ' , X 7S 
IF x7$ = "r'GnTUb90U 
IF x7*<>" "GO 1 ObbOO 
a'(U,22) , ' LD' 



PRINT 
RE T R Y 

PRINT w ( 1 , 2i) , "RUN AbURTEO - CALL PROGRAMMER", 
GOSOb 79U0 
ESCAPE 
GUriJ 69 0 0 

REM " I Eki-INAT Iu.v StCTlUN 900U-9499" 
LET F9»="LP 9020" 

PRINT (/,Ewx = bb0gJ'LF , ;*(l()),"T0TALS",al(b4),b(l):Z»,aab4I l b(«;):ZS 
9020 : ,a)( 1U) ,b(3) Xl», ' LF ' 
9030 BEGIN 

9997 HUM "APXAUO" 

9998 REM "tiVD - APXXOO" 

9999 .END 



Figure All 1-3. Sample Program Organization 
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COMMON ROUTINES 




The following is a 


list of the variables which are used in the common routines coded examples. 


\/A Dl API C 

VAKIAdLl 

NAME 


DESCRIPTION 


ROUTINE 


F7 


Input field flag 


Entry 


F9$ 


Operation device name 
FORMAT; 
r r lie name 
S = Statement number 

RDM FQ<t— "FFFCirrcccc" 
DDll ry-?— rrrrrrjjjj 


Errors 


1 7 


v^uibui vci Licdi puaiuori 


lm try 


1 R 
i_o 


ividAiinuiii iicicj icngLii 


entry 


1 Q 


Line Count 




M 7 
IN / 


Numeric entry flag 0=string 

1=numeric 


Entry 


P7 


Cursor horizontal position 


Entry 


P9 


Page Count 




D O 

Ko 


Numeric entry maximum range 


Entry 


X 


Miscellaneous 


Bell, Password 


x$ 


Miscellaneous 




X7 


Input variable — numeric 


Entry 


X7$ 


Input variable — string 


Entry, Errors, 
Printer Password 


zo$ 


Dashes (For VDT screens) 

OPTION: Use a single character such as\ at the 
end of the field to indicate length of field. 


Entry 


Z7$ 


Zeros 


Entry 


Z8$ 


Blanks 


Entry 



Figure All I-4. Common Routines 
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GLOSSARY OF TERMS 



TERMS AND DEFINITIONS 

ALPHANUMERIC — Characters which are either letters of the alphabet, numerals or special symbols. 

APPLICATION PROGRAM — An application is a specific problem or job to be solved through the use of a 
computer or other data processing machinery. Therefore, an application program is one of several used 
to solve the specific problem. 

Some examples are: Inventory Control, Payroll, Cost Accounting, etc. 

ARRAY — An array is a group of numeric variables with the same name that are referenced through the use 
of a subscript. This can be thought of as being similar to a family of people, all of whom have the same 
surname, but who have different first names. 

For example: Let us assume that the variable X has been defined as having three elements. These would 
be referenced as X(0), X(1 ) and X(2). 

ASCI I CODE — ASCI I is the name of a standard code that assigns specific bit patterns to each sign, symbol, 
letter and operation in a specific set. 

ASCII stands for: American Standard Code for Information Interchange. ASCII is the code used by the 
BASIC/FOUR computer. 

BBI — The acronym for Business BASIC I, the first programming language level used on BASIC/FOUR 
systems. 

BBII -Theacronym for Business BASIC II, the programming language level used on BASIC/FOUR systems. 

BIT — A contraction or abbreviation of binary digit. It signifies the smallest piece of smallest unit of infor- 
mation. In the computer, bits are either on (expressed by a 1 ) or off (expressed by 0). A group of 
eight bits is referred to as a byte. 

BLAN K — The character-code that will result in the printing of a space in a given position. 

BOSS — An acronym for Basic Operating Software System. 



BRANCHING — Branching within a computer program is the means whereby the normal sequence of exe- 
cution is changed. A branch instruction causes the computer to execute an instruction other than the 
next one in sequence within the program. 

Business BASIC Branch instructions are: GOTO . . . ON GOTO . . . GOSUB (See program sequence 
control). 
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BUSINESS BASIC - The interpretive, high level programming language used on BASIC/FOUR computers. 

BYTE - The smallest addressable unit of information in memory. A byte is a group of eight binary bits. A 
byte can contain a value of 0 through 255. 

The first four bits in a byte are referred to as the high order bits. The last four bits in a byte are referred 
to as the low order bits. One byte equals one character. 

CENTRAL PROCESSOR - The portion of a computer that consists of the three main sections - arithmetic 
and control, input/output and memory. 

CODING - To prepare a set of computer instructions required to perform a given action to solve a given 
problem. 

CONCATENATION - Concatenation means to unite or join together. In Business BASIC, concatenation of 
alpha-numeric string information may be accomplished through the use of the + sign. 

CONSTANTS - A constant is a quantity or data item that does not vary in value within a program. 

CONTROL KEYS - The control keys (also called "Motor Bars") are used to reduce key strokes required for 
branching (see INPUT in Reference Manual). 

CONTROL VARIABLE - In Business BASIC, a control variable is a numeric variable required as a parame- 
ter in FOR/NEXT loops. Execution of a FOR statement will set the control variable to a value. Each 
execution of a NEXT statement will increment the value. Each execution of a NEXT statement will 
increment the value in the control variable by the step value, if specified, or by 1 . When the value in the 
control variable exceeds the end value, the FOR/NEXT loop is terminated. 

COUNTER - A variable or a location in memory which can be set to an initial number and increased or de- 
creased by an arbitrary number. 

DATA FILES - Data represents information and information is the assigned meaning. Computers process 
and handle only data. 

A file is a collection of related data. The data is present in the forms of records. 

A data file may be in the form of punched cards, punched paper tape, magnetic tape or may be mag- 
netically recorded on a disc. 

DATA HANDLING FUNCTIONS - Data handling functions are provided to manipulate values contained in 
either string or numeric variables. 

Functions are dividied into groups: 

Those that examine a variable or provide in numeric form a part or characteristic of the variable. 
Those that convert a variable from one form or code to another. 
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DATA LIST - In Business BASIC, the term data list refers to the collection of individual data items to be 
either entered from a file or output to a file. 

The collection of items can be any combination of constant and/or variable information. 

DEBUGGING — The process of determining the correctness of a computer routine, locating any errors, and 
correcting them. Also, the detection and correction of malfunctions in a computer itself. 

DEBUGGING, ON-LINE — The act of debugging a program while time-sharing its execution with an on-line 
process program. 

DEVICE — A device is any hardware mechanism that is created, formed, invented/devised or constructed 
by design. 

Business BASIC refers to a device as a means of inputing information or outputting data. 

Devices are: card readers, paper tape punch units, punch tape readers, magnetic tape units, video dis- 
play terminals. 

Dl RECT FILE — A direct file is a type of file containing data records. As the file is created, and as records 
are written to the file initially, a string value is associated with each record. This value is called the key. 

Direct files may be read: 

RANDOMLY - using an index or key. 

LOGICALLY — according to key sequence or according to record sequence using the index. 

Dl RECT MODE — Direct mode refers to the mode of operation in the Business BASIC language where state- 
ments keyed-in at a terminal are executed immediately after they are entered. 

Statements to be executed immediately, or in direct mode are entered with no statement numbers. 

DIRECTIVE — The Directive is the portion of a Business BASIC statement which specifies the operation to 
be performed. 

Business BASIC Directives are English language word(s). 

Some examples are: LET GOTO END STOP PRINT 

DOCUMENTATION — Design, program and operator documentation which completely describe a system 
(See the USER DOCUMENTATION Section). 

ERR TASK VARIABLE — ERR task variable is a numeric or simple variable which contains a code that re- 
presents the error status of the particular task. 

The name of this variable is "ERR". 

For example, to print its contents the following statement is used: PRINT ERR 
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ERROR HANDLING - Program coding routines which provide for all possible error conditions. 

EXPONENTIATION - Exponentiation means to raise to a power. That is, to multiply a number by itself 
a specified number of times. 

The symbol for exponentiation in Business BASIC is * (up arrow). Example: 2*2 means to raise 2 to 
the power of 2 (result is 4). 

FIELD TERMINATOR - Business BASIC provides for field terminators. All data entered at a terminal must 
be followed by one field terminator unless RE ADRECORD is used for input. (Also called control keys). 

The field terminators are the following keys: 



CR — Carriage Return 

FUNCTION KEY I - FS (Field separator) 

FUNCTION KEY II - GS (Group separator) 

FUNCTION KEY III - RS (Record separator) 

FUNCTION KEY IV - US (Unit separator) 

FLOATING POINT — Floating Point is a system of representing numbers using a pair of numbers, one of 
which represents the digits in the number, the other which represents the power of ten by which the 
number is multiplied. 

Floating Point notation is used in Business BASIC to represent very large or very small numbers. 

Example: The number 1 in Floatingpoint notation is represented as 1 E+01 (that is — 1 times 10 raised 
to the power of 1 ). 



FLOWCHART - A diagram consisting of a set of symbols and connecting lines that show step-by-step pro- 
gression through a procedure or system. 

FORMAT MASK - Format Masks are the means provided by Business BASIC to print numbers in a for- 
matted manner. A Format Mask is a string constant or the name of a string variable. The mask is ap- 
pended to the number to be formatted by using a colon (:). 

Example: PRINT 100:"00000" will display the number as 00100 
PRINT 100:"#####" will display the number as 100 

Format masks provide for proper insertion of commas, decimal points, dollar signs, positive and/or 
negative signs, etc. 

HEXADECIMAL — Hexadecimal refers to a numbering system where there are sixteen possible digits. These 
digits are 0 through 9 and the letters A B C D E and F. 

In the computer, a byte consists of 8 bits which can be divided into 4 high order bits and 4 low order 
bits. Each 4 bits contain a hexadecimal digit. 
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HORIZONTAL POSITION — Horizontal position refers to the position within a line on the terminal or 
printer. 



The terminal has 80 horizontal positions referred to as 0 through 79. 

Printers normally have 132 horizontal positions referred to as 0 through 131. 

INDEXED FILE — An indexed file is a data file that is created by writing records sequentially starting with 
the first physical location for records and continuing to the end. 



Indexed files may be accessed in two ways: 



Sequentially, starting with the first physical location and continuing to the end. 

By using a specific record's location. This is referred to as the index. The first record has an index 

of 0 (zero). 

INTERACTIVE — A system with the ability to directly respond to user commands. 

KEY — A key is the string value associated with each record of a direct file. It may be used to access indi- 
vidual records in the direct file. 



LOGICAL OPERATORS — Logical Operators are used by Business BASIC to define the testing to be done 
in IF statements. 

= is equal to 

< less than 

> greater than 

<> or>< not equal to 

>= or=> greater than or equal to 

<= or=< less than or equal to 



LOOP — A loop is a group of statements in a program that are executed a specified number of times within 
the program at a given point. 

The first statement in a Business BASIC loop is the FOR statement. The last statement in Business 
BASIC loop is the NEXT statement. 



For example: The following loop is executed 5 times . . . 

7100 FOR 1=1 T05 
71 10 ... any BASIC statement 
7120 NEXT I 



MATHEMATICAL SYMBOLS - Mathematical symbols are characters recognized by Business BASIC to 
represent mathematical operations to be performed. 





+ 


tells the computer to add 








tells the computer to subtract 






* 


tells the computer to multiply 






/ 


tells the computer to divide 






A 


tells the computer to raise to a power 
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MNEMONIC CONSTANTS - A mnemonic constant consists of two characters, enclosed in primes (') and is 
used to cause a specific action to occur on a peripheral device or on a terminal. 

NUMERIC ARRAYS - A numeric array is a group of numeric variables with the same name that are refer- 
enced through the use of a subscript. This can be thought of as similar to a family of people, all of 
whom have the same surname, but each of which have a different first name. (See ARRAY) 

NUMERIC CONSTANT - A numeric constant is a number whose value does not vary within a program. 

NUMERIC FIELD - A numeric field is an item of data present in a data record whose contents are always 
numeric information. 

A numeric field is represented by using a simple variable name, numeric array, or a numeric constant. 
ON-LINE — Directly interacting with a computer. 

OVERLAY - An overlay is a continuation program. It is also often referred to as a LINK. 

PARAMETER - A parameter is a required and/or optional value used in association with a statement direc- 
tive to define in detail the action to be taken by the computer. 

Parameters include or reference all variable or constant information that may be associated with the 
particular BASIC statement. The type of information included depends upon the particular directive. 

Parameters often consist of variables. 

PERIPHERAL DEVICE — A peripheral device is a means of inputting information to the computer or 
outputting information from the computer. 

A BASIC/FOUR system may have any of the following peripheral devices: Card Reader, Paper Punch, 
Paper Tape Reader, Magnetic Tape Units, Video Display Terminals and Printer. (See DEVICE) 

PRECISION STATEMENT — The precision statement, after it is executed, specifies the number of decimal 
places to the right of the decimal point that final results and intermediate results of mathematical ex- 
pressions are to be carried. 

Business BASIC provides for a minimum of 0 (none) through a maximum of 14 digits to the right of 
the decimal point. 

PROGRAM — A program is a series of instructions which the computer follows to perform a given task. 
These instructions must be written in a language understood by both man and machine. 

PROGRAM FILE — A program file is a disc file that contains a Business BASIC program. 

PROGRAM INITIALIZATION — Program initialization refers to certain operations normally performed at 
the beginning of a computer program. Business BASIC provides three directives which can be used for 
initialization. These are BEGIN, CLEAR, and RESET. 
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The first statement in a Business BASIC program should be the BEGIN statement. This will clear all 
data, close all files and reset any incomplete loops and resets the precision to 2. The CLEAR statement 
only clears data and resets incomplete loops and resets the precision to 2. The RESET statement only 
resets incomplete loops and resets the precision to 2. 

PROGRAM LANGUAGE - A programming language is basically the means of communication between man 
and computer. It is a set of rules and conventions that govern the manner and sequence in which instruc- 
tions are written or specified for execution by a computer. 

PROGRAM LOOP — A program loop is a group of statements in a program that are executed a specified 
number of times within the program at a given point. (See LOOP) 

PROGRAM SEQUENCE CONTROL — Program sequence control statements change the order of processing 
statements within a program. 

Business BASIC provides two statements that can alter the sequence of processing statements in a pro- 
gram. These are GOTO and ON/GOTO. (See BRANCHING) 

PROGRAM TERMINATION — Business BASIC provides two directives to terminate processing of a program. 
The two directives function in the same manner. When executed, all files and/or devices opened are 
closed and thus made available for use. Execution of a program termination statement does not change 
the contents of any variables. The two statements provided are: STOP and END. , 

RANDOM — Permitting access to stored data in no particular sequence. 

RECORD — A record consists of a group of data elements or fields that relate to a single major item. A col- 
lection of records is called a file. 

For example: An inventory file might consist of records that would each relate to a single inventory 
item. Each record might contain the inventory item code, a description of the item, its price, the cur- 
rent quantity on hand, the quantity on order, etc. 

ROUND — Round refers to a manner of adjusting a decimal number. When the computer rounds a number, 
the least significant digit is deleted, and the remaining part of the number is adjusted based on the fol- 
lowing: 

1 . If the least significant digit is 4 or less, that digit is merely deleted to obtain the rounded result. 

2. If the least significant digit is 5 or more, that digit is deleted and 1 is added to the next higher sig- 
nificant digit. 

For example: 21 .534 is 21 .53 if rounded; 21 .536 is 21 .54 if rounded. 
ROUTINE — A series of computer instructions which perform a specific, limited task. 
SECTOR — The smallest accessible portion of a disc. 
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SEQUENTIAL - Sequential means an order. In Business BASIC, sequential refers to logical order of records 
in a disc file or a file present on a peripheral device. 

An example of sequential is the manner in which a program is executed. That is, in statement number 
sequence. The first statement of a program is executed first, followed by the second, followed by the 
third and so forth. 

SIGNIFICANT DIGIT - Significant digit is the first non-zero digit in a number. 
For example: in the number 0003021 1 , the first significant digit is 3. 

The least significant digit in a number is that digit which contributes the smallest quantity to the value 
of the number. 

For example: in the number 21 .5436, the least significant digit is 6. 

SIMPLE VARIABLE - A simple variable can contain numeric information only. It can be named as any 
single alphabetic character (A-Z) or as a single alphabetic character followed by a single numeric 
digit (0-9). 

The following are all valid simple variable names: A J8 X9 G P1 (See VARIABLE). 

SLEW — Slew refers to the movement of paper in a printer through a distance greater than the normal line 
spacing without printing. 

SOFTWARE — The programs or routines, and supporting documentation, which instruct the operations of 
a computer. 

STATEMENT — An instruction that defines an operation and which as a unit causes the computer to com- 
plete that operation. 

STRING — A string is a collection of characters that are a mixture of numbers, alphabetic characters and/or 
special characters such as punctuation. 

In Business BASIC, strings may be present in constant or variable form. (See STRING VARIABLE, 
STRING CONSTANT) 

STRING CONSTANT — A string constant is a group of alphabetic and/or numeric characters, enclosed in 
quotation marks, that do not change within a program. 

String constants are often used to communicate with an operator via the terminal. 

For example: "This is a string constant" "So is this" 

STRING FIELD — A string field is a data item within a record whose contents are a mixture of alphabetic 
and/or numeric information. 

A string field may be represented by either a string constant or a string variable. 
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STRING VARIABLE — A string variable is a variable containing a mixture of alphabetic and numeric infor- 
mation. String variables may be named as any single alphabetic character (A— Z) followed by a dollar 
sign ($) or as a combination of a single alphabetic character (A— Z) followed by a single numeric digit 
(0—9) followed by a dollar sign ($). 

Some examples of string variable names are: A$ A8$. N2$ U$ Z1$ 

SUBROUTINE — A subroutine is a series of program statements that are to be executed in more than one 
place within a given program. Subroutines may be called for execution at any point within the program. 

The Business BASIC directive used to transfer program control to a subroutine is the GOSU B instruction. 

Program control will be transferred back to the statement following the GOSUB statement when a re- 
turn is executed. Return should be the last statement in a subroutine. 

SUBSCRIPT — A subscript is a portion of a string or an array. To reference a portion of a string, the pro- 
grammer must specify the starting position within the string. He may optionally specify the number of 
characters to be referenced. 

For example: Assume the variable A$ contains 5 characters, ABCDE 

A$(1,3) is the ABC 
A$(5,1) is the E 

SYNTAX — Syntax is the rules governing the structure of program statements or expressions in the Business 
BASIC language. 

SYSTEM — A collection of parts or devices that forms and operates, as an organized whole through some 
form of regulated interaction. 

SYSTEM DESIGN — The definition and documentation of the system requirements, function relationships 
and technical procedures, necessary to develope and support the system. 

SYSTEM VARIABLES — There are two system variables in the Business BASIC language: 

1 . TIM is a numeric variable containing the current value of the built in computer clock expressed in 
ten thousands of an hour. 

2. DAY is a string variable containing eight characters that are its current contents. 

The system directives provided to change these variables are SETTIME and SETDAY respectively. 
TASK — Any user program. 
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